[OffgridwithJD]

Stacked on #1461 (merge after it). Two commits: 0d4702b3 (the twin and the shell fixes) and 7e0d2714 (the ledger seed). This is the last suite of #1341 item 129, after pg_dump_roundtrip (#1458) and pg_upgrade (#1461).

What was wrong

• "compact replays identically" compared a state compact never changed. Probed: by the time compact ran on r, vacuum had already reclaimed every deleted row, so compact returned 0 and removed no row group. The fixture now gives compact one fully deleted row group, from an INSERT of its own followed by a DELETE. A new arm, "compact retired the fully deleted row group on the primary", requires retired|row groups lost = 1|1.
• Nothing showed that vacuum did anything. A new arm, "vacuum rewrote r into a new relfilenode on the primary", checks that.
• The module-less replay arms passed if r2's second INSERT failed: the LSN was still reachable, and both hashes still agreed. A premise now pins the primary at 9000 rows.

Red first (PG18, both shells, then the twin)

mutant	old shell (41)	new shell (44)	twin
pgcolumnar_vacuum returns before rewriting	green	red: the vacuum arm	red: the vacuum arm
compact retires nothing (retired = 0)	red only on the truncate precondition	red: the compact arm and the truncate precondition	red: the compact arm
no XLOG_SMGR_TRUNCATE record	red: the fork arm	red: the fork arm (standby 753664)	red: same
data and gap pages written without WAL	red: 8 arms	red: the same 8	red: its first, a failed read on the standby (could not read blocks)

The twin stops at its first red, so under the last two mutants it shows one arm where the shell shows several. The ledger is dated from the shell's logs.

The twin

test_replication.py carries all 44 checks by the shell's name (compare_to_bash: 44 literal, 0 missing). It runs on three private clusters, built with pgc_cluster.Cluster and pick_port slots 20, 21 and 22:

• a primary;
• a pg_basebackup -R -C -S streaming standby;
• a backup restored with no upstream.

Like the shell, the twin restarts the standby without the module and then with it. Every comparison on the standby side goes through query_error, so a failed read can't compare equal to anything. It's one test function, because the scenario is sequential.

Runs

Head is 44/44 in both twins on each of 15, 16, 17, 18 and 19. The twin is also 44/44 run as root (sudo, PG18): pgc_cluster.Cluster already drops to postgres for initdb and pg_ctl, and pg_basebackup is a client tool.

Ledger

• The suite had no rows. All 44 checks enter, 11 dated by the four mutations above and 33 never.
• The 33 are:
  • the backup, restore and standby controls;
  • the primary's pins;
  • the projection arms, which a bytewise copy carries without any columnar WAL;
  • the row-count comparisons, which count(*) answers from the catalog;
  • the paused-replay control;
  • the module-less standby's arms, which no product mutation can redden while every record is a core type.
• suites_not_covered 212 → 211. The census is 3839 / 2812 / 1027.
• pgc_ledger.py gate returns rc 0 against origin/main (ceiling 219 → 211).

Counts and guards

• cluster_tests 681 → 682, and pytest collects 682.
• COMPLETE gains replication, and TESTS.md gains §152.
• The NO_CLUSTER guards pass (438), harness_selftest.sh gives 1245, and docs_style.sh passes.

🤖 Generated with Claude Code

[jdatcmd]

Approving 3e800eb.

Measured on PG17: replication.sh 44/44, and test_replication.py 44 checks, on three private clusters, run as root. The tsv at this head (3839 / 2812 / 1027) matches the description and its budget.

Your vacuum claim, with the mutant run myself: pgcolumnar_vacuum returns before it rewrites anything (PG_RETURN_VOID straight after reading its argument).

shell	result
main's replication.sh	41/41 green, as you said
this PR's	43/44: vacuum rewrote r into a new relfilenode on the primary, got [no] want [yes]
the twin	the same arm, got 'no' want 'yes'

I took the compact, XLOG_SMGR_TRUNCATE and WAL-less-page mutants from your table.

[jdatcmd]

A correction to my approval: its first line says 3e800eb, the head named in your description. I measured, and approved, 7e0d271, this branch rebased onto #1461's 70c186e, with the twin and ledger commits 0d4702b and 7e0d271. Every number in my review is from 7e0d271.

[jdatcmd]

Re-approving 3f27e47, the restate onto main db56168. I compared every commit's patch with the approved stack using git range-diff. The test and source commits are unchanged, and the ledger-seed commits changed only by re-anchoring on #1470. The census at this head matches its budget paragraph, and the counts step consistently. At #1467's head: the guards pass (438), 687 collected (matching the file), and harness_selftest is 1245/1245.