Test coverage: physical replication / standby redo and pg_basebackup

[ChronicallyJD]

Gap

Physical/streaming replication and pg_basebackup have no test coverage. The extension WAL-logs into the relation main fork and uses custom SMGR redo (ColumnarTruncateMainFork, XLogInsert(RM_SMGR_ID…)). Standby replay requires the module loaded on the standby with the correct redo routines — a hazard the code comments in native_cancel.sh and wal_envelope.sh explicitly name. Yet wal_envelope.sh only structurally greps the C source for the WAL envelope; nothing stands up a replica and replays columnar WAL, and recovery.sh covers in-place crash redo but not base-backup + replay on a second cluster.

Why this blocks a public release

Most production PostgreSQL runs with a standby. If columnar WAL does not replay correctly on a standby (or pg_basebackup + start yields a corrupt or unreadable columnar table), that is silent divergence or data loss on failover. Acceptable in alpha only if "single-node only, no physical replication tested" is documented.

Suggested acceptance criteria

• A suite that: starts a primary with pgcolumnar preloaded, pg_basebackup to a standby (module also preloaded), streams a columnar workload (insert/delete/compact/truncate), and asserts the standby's columnar tables match the primary after replay.
• Cover the SMGR-truncate redo path specifically (the envelope wal_envelope.sh only greps).

Found in a release-readiness review; sibling of the pg_upgrade and format-compatibility issues.

[ChronicallyJD]

Confirmed by #251's Scenario 3: the premise in this issue -- "requires the module loaded on the standby with the correct redo routines" -- was mine and wrong. Every record emitted is a core type: data pages via log_newpage/log_newpage_buffer (RM_XLOG_ID) and one XLogInsert(RM_SMGR_ID, XLOG_SMGR_TRUNCATE), so redo is core's; the module is only needed to read the table, which is a different thing from replaying the bytes. #251 turns the standing WAL constraint into a test rather than an argument. The remaining coverage this issue asked for (a real standby replaying columnar WAL, and pg_basebackup) is what #251 delivers.

[jdatcmd]

Closed by #251 (1341ae8). test/replication.sh: pg_basebackup to a second cluster, streams a columnar workload, asserts the standby matches after replay across insert/delete/update, vacuum, compact and the SMGR truncate record. 21 checks, in the matrix.

One correction to this issue's premise, recorded because it matters for the WAL constraint: standby replay does not require the module loaded. Every record emitted is a core type (log_newpage / log_newpage_buffer, and one XLogInsert(RM_SMGR_ID, XLOG_SMGR_TRUNCATE)); there is no custom rmgr. The module is needed to read a columnar table, which needs the AM handler, not to replay its bytes. Scenario 3 asserts that directly: a standby with shared_preload_libraries emptied replays columnar WAL past the primary's LSN without PANIC, and reads the table once the module is restored.

Proven by removal: dropping -R from pg_basebackup so the copy is not a replica fails 13 of 21 checks.