A modern, delicious implementation of the Nix package manager, focused on correctness, usability, and growth — and committed to doing right by its community
https://lix.systems
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:
|
||
|---|---|---|
| .github | ||
| bench | ||
| contrib | ||
| doc | ||
| maintainers | ||
| meson | ||
| misc | ||
| nix-support | ||
| perl | ||
| releng | ||
| scripts | ||
| src | ||
| subprojects | ||
| tests | ||
| .clang-format | ||
| .clang-tidy | ||
| .dir-locals.el | ||
| .editorconfig | ||
| .envrc | ||
| .gitignore | ||
| .this-is-lix | ||
| Cargo.lock | ||
| Cargo.toml | ||
| CONTRIBUTING.md | ||
| COPYING | ||
| default.nix | ||
| docker.nix | ||
| flake.lock | ||
| flake.nix | ||
| justfile | ||
| meson.build | ||
| meson.options | ||
| package.nix | ||
| README.md | ||
| shell.nix | ||
| treefmt.toml | ||
| version.json | ||
Lix
Lix is an implementation of Nix, a powerful package management system for Linux and other Unix systems that makes package management reliable and reproducible.
Read more about us at https://lix.systems.
Installation
On Linux and macOS the easiest way to install Lix is to run the following shell command (as a user other than root):
$ curl -sSf -L https://install.lix.systems/lix | sh -s -- install
For systems that already have a Nix implementation installed, such as NixOS systems, read our install page
Building And Developing
See our Hacking guide in our manual for instruction on how to to set up a development environment and build Lix from source.
Additional Resources
License
Lix is released under LGPL-2.1-or-later.