Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

store: Use a different locking strategy for deployments #4010

Merged
merged 1 commit into from
Oct 13, 2022
Merged

Conversation

lutter
Copy link
Collaborator

@lutter lutter commented Sep 29, 2022

We used 'select for update' to lock a deployment against concurrent writes. It seems that that has bad consequences for performance in general; advisory locks are more lightweight than locking table rows, hopefully using them here will help write performance.

@@ -11,6 +11,8 @@
//! We use the following 2x 32-bit locks
//! * 1, n: to lock copying of the deployment with id n in the destination
//! shard
//! * 2, n: to lock the deployment with id n to make sure only one write
//! happens to it
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might help readability to introduce a constant for the 1 and 2.

We used 'select for update' to lock a deployment against concurrent
writes. It seems that that has bad consequences for performance in general;
advisory locks are more lightweight than locking table rows, hopefully
using them here will help write performance.
@lutter lutter merged commit 55f2f08 into master Oct 13, 2022
@lutter lutter deleted the lutter/lock branch October 13, 2022 16:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants