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

Make sure to take sqlite write locks upfront #2479

Merged
merged 1 commit into from
Oct 27, 2024
Merged

Conversation

tbodt
Copy link
Member

@tbodt tbodt commented Oct 27, 2024

Fun quirk of sqlite is that if you BEGIN DEFERRED and then do a read statement and then another process concurrently does a write and then the first process does a write statement on the same transaction, it will immediately return SQLITE_BUSY because it's impossible to do a write against a past version of the database. To fix this we need to use BEGIN IMMEDIATE to take a write lock upfront on any transaction that will need to write.

Fun quirk of sqlite is that if you BEGIN DEFERRED and then do a read
statement and then another process concurrently does a write and then
the first process does a write statement on the same transaction, it
will immediately return SQLITE_BUSY because it's impossible to do a
write against a past version of the database. To fix this we need to use
BEGIN IMMEDIATE to take a write lock upfront on any transaction that
will need to write.
@tbodt tbodt merged commit 59f0f14 into master Oct 27, 2024
12 checks passed
@tbodt tbodt deleted the fakefs-write-lock branch October 27, 2024 22:17
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.

1 participant