avoid reposize database locking overhead when not needed
Only when the preferred content expression being matched uses balanced preferred content is this overhead needed. It might be possible to eliminate the locking entirely. Eg, check the live changes before and after the action and re-run if they are not stable. For now, this is good enough, it avoids existing preferred content getting slow. If balanced preferred content turns out to be too slow to check, that could be tried later.
This commit is contained in:
parent
09955deebe
commit
e006acef22
6 changed files with 43 additions and 12 deletions
|
@ -37,14 +37,6 @@ Planned schedule of work:
|
|||
|
||||
* Test that live repo size data is correct and really works.
|
||||
|
||||
* Avoid using checkLiveUpdate except when checking a preferred content
|
||||
expression that does use balanced preferred content. No reason to pay
|
||||
its time penalty otherwise.
|
||||
|
||||
Alternatively, make it not use file locking. It could rely on a database
|
||||
transaction, or it could check the live changes before and after and
|
||||
re-run the Annex action if they are not stable.
|
||||
|
||||
* When loading the live update table, check if PIDs in it are still
|
||||
running (and are still git-annex), and if not, remove stale entries
|
||||
from it, which can accumulate when processes are interrupted.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue