forked from lix-project/lix
raito
2a7a6cb85a
Sometimes, a path can disappear from the `ValidPaths` table (I have 23
such cases on my 1.4TB Nix store).
When this occurs and you try to run a garbage collection,
`queryReferrers` will report no referrer because it's performing a
*RIGHT JOIN* between `Refs` and `ValidPaths`, finally, when you issue
the deletion SQL statement, this will throw an uncaught exception from
SQLite side regarding a foreign key violation because `reference` in
`Refs` is a foreign key to `ValidPaths` (which we are trying to delete).
Why can this happen?
Two reasons:
* `PRAGMA foreign_keys=off;` will disable deletion on cascade.
* Trigger recursion *limits*, a deletion on cascade is a *trigger*, when
a delete is issued and it triggers a bunch of deletion on cascade,
there's a documented limit by SQLite: https://www.sqlite.org/limits.html#max_trigger_depth
> Recursion limit on foreign key actions. The SQLITE_MAX_TRIGGER_DEPTH
> and SQLITE_LIMIT_TRIGGER_DEPTH settings determine the maximum
> allowable depth of trigger program recursion. For the purposes of
> these limits, foreign key actions are considered trigger programs. The
> PRAGMA recursive_triggers setting does not affect the operation of
> foreign key actions. It is not possible to disable recursive foreign
> key actions.
As I do not see easy ways to solve the root cause, garbage collection
should be self-healing in that regards, so I propose to invalidate
phantom referrers as we go.
As part of a work improving the consistency of the SQLite database, it
would make sense to count how many times this happen and try to find
ways to reproduce this issue.
Change-Id:
|
||
|---|---|---|
| .. | ||
| asan-options | ||
| build-remote | ||
| libcmd | ||
| libexpr | ||
| libfetchers | ||
| libmain | ||
| libstore | ||
| libutil | ||
| lix-doc | ||
| nix | ||
| nix-build | ||
| nix-channel | ||
| nix-collect-garbage | ||
| nix-copy-closure | ||
| nix-env | ||
| nix-instantiate | ||
| nix-store | ||
| pch | ||
| lix-base.pc.in | ||
| meson.build | ||