-
Notifications
You must be signed in to change notification settings - Fork 583
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
db_sqlite: new parameters and minor improvements #3545
Conversation
ptr->con is always NULL at this moment
sqlite3_db_config with SQLITE_DBCONFIG_ENABLE_LOAD_EXTENSION affects only C-API without enabling SQL function load_extension()
The proper way to handle a locked database is to use a busy timeout. Previously, the behavior resulted in an infinite lock for the process attempting to write to the locked database. The default value for the busy timeout has been set to 500 ms to avoid immediate errors when short database locks occur.
eb8d1b3
to
c307279
Compare
c307279
to
0cdbb85
Compare
@vasilevalex , thanks for your contribution here. Do you think it is doable to split PR into "fixes" and "new stuff" ? Why? as if we do this, we can backport the "fixes". Otherwise, as mixed with new features, the backport will not be possible. |
yes, sure, I'll split it in 2 PRs |
Thanks @vasilevalex . For the new stuff, will you rebase this PR or create a new one (and trash this one) ? |
Hi @bogdan-iancu . I'll make new one tomorrow, then I need to add information here and will close this one. |
Summary
Details
The PR was started as new feature, but fixed some issues during implementation.
Solution
Please review commits
Compatibility
The original behavior has been changed. If the database is locked, the process attempting to access it will no longer enter an infinite loop. Instead, it will return an error after the default timeout of 500 ms (this value can be modified as module parameter).