jonnify·persistence /echo-persistence/engines/postgres-wal

Module 11 · Chapter III — The engines

Postgres WAL on the floor.

The engines chapter built one durable floor — Champ accepts, CubDB/Fjall holds, Graft commits one LSN to Tigris behind the fence. But that floor carries the available-first tier: the cache and the stream log. The money lives elsewhere — in Postgres, the consistency-first ledger — and its write-ahead log never reaches the floor. This module is the PROPOSED design for bringing the ledger's WAL LSN onto the same Tigris floor and the same one cursor.

Forward-tense. Unlike Modules 7–10, nothing here is shipped. The design is recorded and ruled (graft.pg-wal-archive.design.md, the fork ruled A→B); this page teaches the proposal, not as-built code.
The ledger joins the floor. The consistency-first Postgres ledger (left) carries its own WAL LSN; the available-first Graft floor (right) commits its LSN to Tigris and rides the change-feed. Tap a step to see how the WAL would join.
Postgres ledger consistency-first · the money WAL LSN Graft floor available-first · cache + log commit LSN Tigris /segments /logs/…/commits /wal (proposed) change-feed · the one cursor commit LSN WAL LSN commit archive_command · create-if-not-exists
readout · Tap a step. Today the commit LSN rides the feed and replicates to Tigris; the WAL LSN does not — the ledger's durability is off the floor.
§1

Why the ledger isn't on the floor — yet

graft.pg-wal-archive.design.md

The platform segments its CAP trade per surface, and durability follows the split. The available-first tier — the near-cache and the EchoMQ stream log — rides the floor this chapter built: its pages and its trimmed stream slices become Graft commits replicated to Tigris, and the commit LSN binds replica, consumer, and store on one cursor (Module 13). The consistency-first ledger is a different surface: balances and an append-only transaction ledger in Postgres, mutated all-or-nothing, where a committed payout must never be lost. Its durable record is its own write-ahead log, with its own LSN — a different log over different bytes. Graft replicating its commit LSN to Tigris does not archive Postgres's WAL; the two are disjoint, and the money's off-site recovery is, today, unsolved on the floor.

That is the gap this module closes in design. Postgres point-in-time recovery and a streaming replica are the ledger's launch prerequisites (codemojex.postgres.md, “the work before real money”), and the question is whether to answer them with a parallel, off-platform backup tool or to bring the WAL onto the engine, the fence, the bucket, and the cursor the rest of the floor already shares. The design surfaces that as a four-arm fork and rules it; the dives walk the idea, the mechanism, and the decision.

§2

The three dives

module 11
§3

Status & check

Status · PROPOSED

The fork is recorded and ruled in graft.pg-wal-archive.design.md: Arm A (WAL-G/pgBackRest → Tigris) then Arm B (a read-only Graft WAL-frontier lane on the change-feed); Arm C (a Graft-native WAL-archive Volume) is deferred, Arm D (a Graft pageserver under a replica) is declined at present scale. No arm is built.

Check

Without code: why doesn't the Graft+Tigris floor already cover Postgres PITR, and what single object-store primitive lets the WAL ride the same fence as a Graft commit? “Two disjoint logs; create-if-not-exists” means you have the module.

§4

References & sources