More robust handling of ErrorBusy when writing to sqlite databases
authorJoey Hess <joeyh@joeyh.name>
Mon, 17 Oct 2022 19:56:19 +0000 (15:56 -0400)
committerJoey Hess <joeyh@joeyh.name>
Mon, 17 Oct 2022 19:56:19 +0000 (15:56 -0400)
commit3149a1e2fe6bd907cb9e1852451621e8386bf2b2
tree5d138de9132adb625012a7ff68ce3c43aa9aa7d3
parent0d762acf7ebf2406dc4f0ad167b580e3a3801f1e
More robust handling of ErrorBusy when writing to sqlite databases

While ErrorBusy and other exceptions were caught and the write retried for
up to 10 seconds, it was still possible for git-annex to eventually
give up and error out without writing to the database. Now it will retry
as long as necessary.

This does mean that, if one git-annex process is suspended just as sqlite
has locked the database for writing, another git-annex that tries to write
it it might get stuck retrying forever. But, that could already happen when
opening the sqlite database, which retries forever on ErrorBusy. This is an
area where git-annex is known to not behave well, there's a todo about the
general case of it.

Sponsored-by: Dartmouth College's Datalad project
CHANGELOG
Database/Handle.hs
doc/bugs/get_is_busy_doing_nothing/comment_27_45168f110bded2f8c8f9777e1edda945._comment [new file with mode: 0644]
doc/todo/withExclusiveLock_blocking_issue.mdwn