pub const AUTO_SNAPSHOT_RETENTION: Option<u32>;Expand description
How many WAL archives a snapshot mushroomdb takes on its own keeps.
None = all of them. Retention is configured, never defaulted: deleting
history nobody asked to delete is not a default worth having.
Archiving moves the WAL aside rather than deleting it, so without a bound
every automatic snapshot leaves one more file behind and nothing ever
reclaims them. On a dogfooded repository that is a new archive per
SNAPSHOT_WAL_BYTES of churn, for as long as the store exists — and that
growth is the argument for the default, not against it: the reach archives
exist to preserve — node_history, edge_history, was_linked — is
exactly what pruning costs, so an automatic snapshot never volunteers to
pay it. mushroomdb stats and mushroomdb doctor both print where history
currently starts, and mushroomdb snapshot <db> --retention N is how a
caller bounds the directory once they have decided the trade is worth it.
One consequence is worth stating plainly for whoever does set a bound,
because it is not proportional. The first prune breaks the genesis chain,
and open_at refuses any commit it cannot reconstruct from a complete
prefix — so from that point it answers for commits past the last snapshot
and no further, even though the retained archives still answer
node_history and was_linked over their own window. Time travel to a
point-in-time state is therefore bounded by the last snapshot once a store
has churned this far; the history reads are bounded by the retention.
Only the automatic path takes this default. mushroomdb snapshot is a
thing the user asked for, and --retention N is theirs to set: an
explicit snapshot with no --retention still keeps every archive.