pub const AUTO_SNAPSHOT_RETENTION: u32 = 8;Expand description
How many WAL archives a snapshot mushroomdb takes on its own keeps.
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.
Eight is the compromise. The reach archives exist to preserve —
node_history, edge_history, was_linked — is what the bound costs, and
eight archives is eight snapshot intervals of it, which on the 4 MiB
threshold is tens of megabytes of history and weeks of ordinary commit
traffic. Beyond that the disk is a worse trade than the reach.
One consequence is worth stating plainly, 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
eight 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 is bounded. 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, because deleting history
nobody asked to delete is not a default worth having.