sqlite: set busy timeout to 100s
Only one process can write to the sqlite db at the same time, if another process tries to use it at that time it fails and a database is locked error is returned. If this happens sqlite should keep retrying until it can write. To do that we can just set the _busy_timeout option. A 100s timeout should be enough even on slower systems but not to much in case there is a deadlock so it still returns in a reasonable time. [NO NEW TESTS NEEDED] I think we strongly need to consider some form of parallel stress testing to catch bugs like this. Fixes #20809 Signed-off-by: Paul Holzinger <pholzing@redhat.com>
This commit is contained in:
parent
06c41b614d
commit
5b3d82f9bc
|
|
@ -40,13 +40,17 @@ const (
|
|||
sqliteOptionForeignKeys = "&_foreign_keys=1"
|
||||
// Make sure that transactions happen exclusively.
|
||||
sqliteOptionTXLock = "&_txlock=exclusive"
|
||||
// Make sure busy timeout is set to high value to keep retying when the db is locked.
|
||||
// Timeout is in ms, so set it to 100s to have enough time to retry the operations.
|
||||
sqliteOptionBusyTimeout = "&_busy_timeout=100000"
|
||||
|
||||
// Assembled sqlite options used when opening the database.
|
||||
sqliteOptions = "db.sql?" +
|
||||
sqliteOptionLocation +
|
||||
sqliteOptionSynchronous +
|
||||
sqliteOptionForeignKeys +
|
||||
sqliteOptionTXLock
|
||||
sqliteOptionTXLock +
|
||||
sqliteOptionBusyTimeout
|
||||
)
|
||||
|
||||
// NewSqliteState creates a new SQLite-backed state database.
|
||||
|
|
|
|||
Loading…
Reference in New Issue