comment
This commit is contained in:
parent
331c97df88
commit
a57ad1e226
1 changed files with 22 additions and 0 deletions
|
@ -0,0 +1,22 @@
|
||||||
|
[[!comment format=mdwn
|
||||||
|
username="joey"
|
||||||
|
subject="""comment 20"""
|
||||||
|
date="2022-06-06T16:12:53Z"
|
||||||
|
content="""
|
||||||
|
It does occur to me that one "solution" might be to have flushDbQueue
|
||||||
|
not rethrow the exception, and just re-enqueue the write. Then, if a write
|
||||||
|
fails in the middle of a long git-annex command, it will just queue up
|
||||||
|
sqlite changes until later. And hopefully whatever is preventing writing to
|
||||||
|
the database at that time would later resolve itself. At shutdown, it would
|
||||||
|
need to make sure to flush the remaining queue and not ignore a write
|
||||||
|
failure then.
|
||||||
|
|
||||||
|
That has the potential problem that, if the write keeps failing, it might
|
||||||
|
end up buffering a large number of writes in memory, and since the queue
|
||||||
|
would be full, it would be trying to write every time. So it would both use
|
||||||
|
an ever-growing amount of memory, and be slowed down by the write attempts.
|
||||||
|
|
||||||
|
Still, it does give it something better to do while the write is failing
|
||||||
|
than sleeping and retrying, eg to do the rest of the work it's been asked
|
||||||
|
to do.
|
||||||
|
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue