wal-and-xloglisted

# WAL & XLOG — operational skill This is the procedural cookbook. For the conceptual model (LSNs, FPI, checkpoints, rmgrs) read `knowledge/architecture/wal.md` first. ## When to use what | Situation | Use | |---|---| | In-tree access method, new record type | new builtin rmgr (RmgrId < 128) — needs core patch | | Extension that just modifies pages (small new index AM, prototype) | **Generic WAL** (`generic_xlog.c`) | | Extension that needs compact records, logical decoding, or custom replay logic | **Custom rmgr** via `RegisterCustomRmgr` | | Optimisation hint that can be re-derived from authoritative state | **no WAL** — use `MarkBufferDirtyHint()` | | Tracking commit/abort of an XID (you almost never need to do this) | not a WAL concern — it's pg_xact | [from-comment `source/src/backend/access/transam/rmgr.c:97-104`; from-code `source/src/backend/access/transam/generic_xlog.c:1-12`] ## Custom rmgr vs Generic WAL — decision Choose **Generic WAL** when: - You're prototyping or your extension is small. - Record volume isn't a bottleneck (per-page delta can be larger than a hand-rolled record). - You don't need logical decoding. Choose **Custom rmgr** when: - Record volume matters (frequent small changes). - You need replay-time semantics beyond "apply this page delta" (e.g. cross-page invariants, structure-specific recovery). - You need a `rm_decode` hook for logical decoding. - You want pretty `pg_waldump` output via `rm_desc` / `rm_identify`. ## Custom rmgr — ful