history: Add a pathhistory inn.conf parameter#363
Closed
kev009 wants to merge 2 commits into
Closed
Conversation
innd deliberately opens the history without HIS_CREAT (a missing database at startup is more likely a mount failure than a fresh install, and auto-creating an empty history would re-accept everything), so initialization must happen beforehand. "make install" only knew the hisv6 procedure (touch history + makedbz -i -o), which with hismethod set to hissqlite leaves a stray empty hisv6 database and no .sqlite, and innd then refuses to start. The initializer is makehistory with no arguments: it opens the history with HIS_CREAT, and on an empty spool that simply creates an initialized empty database (the makedbz -i -o equivalent; verified, and the result opens through the WAL direct-reader path). A bare "touch history.sqlite" is not sufficient: a zero-byte file has no schema and is not in WAL mode, and both innd and the readers refuse it cleanly. site/Makefile now branches the history-creation recipe on the configured hismethod: for hissqlite it runs makehistory once, keyed on history.sqlite being absent so reinstalls stay no-ops; the hisv6 path is unchanged, and DESTDIR (packaging) installs take the historical path since the installed binaries and inn.conf are not available to query. Document the manual procedure in INSTALL next to the makedbz instructions and in hissqlite(5).
pathhistory is a directory, like every other path* parameter, and defaults to the value of pathdb, so existing installations are unchanged. It covers the whole history file family: the history(5) text file and its dbz indices (and their .n rebuild variants) for hisv6, or history.sqlite and its WAL files for hissqlite. The tombstone logs stay in pathdb for now as they are expiry state, not history files. Particularly important for hissqlite: a ZFS dataset should have a recordsize matching the database page size (see hissqlite(5)).
Julien-Elie
pushed a commit
that referenced
this pull request
Jul 16, 2026
pathhistory is a directory, like every other path* parameter, and defaults to the value of pathdb, so existing installations are unchanged. It covers the whole history file family: the history(5) text file and its dbz indices (and their .n rebuild variants) for hisv6, or history.sqlite and its WAL files for hissqlite. The tombstone logs stay in pathdb for now as they are expiry state, not history files. Particularly important for hissqlite: a ZFS dataset should have a recordsize matching the database page size (see hissqlite(5)). see #363
Contributor
|
Many thanks for this move! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
(Builds on top of #361)
pathhistory is a directory, like every other path* parameter, and defaults
to the value of pathdb, so existing installations are unchanged. It covers
the whole history file family: the history(5) text file and its dbz indices
(and their .n rebuild variants) for hisv6, or history.sqlite and its WAL
files for hissqlite. The tombstone logs stay in pathdb for now as they
are expiry state, not history files.
Particularly important for hissqlite: a ZFS dataset should have a
recordsize matching the database page size (see hissqlite(5)).