You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Analysis of the last three days of commits (50 commits, Jul 15–17 2026, v19 beta) identified recurring bug classes behind the fixes (unregistered-buffer WAL omissions, summarizer blind spots, deparse round-trip failures, recovery-boundary state machines, unvalidated wire/file input, boundary off-by-ones). A source-verified audit produced this prioritized plan.
Key verified findings
wal_consistency_checking is structurally blind to visibility-map corruption: rm_mask gets no fork number, so heap_mask()/mask_unused_space() wipes the whole VM bitmap before comparison, and mask_page_hint_bits() clears PD_ALL_VISIBLE. The stale-VM-bit corruption fixed in ed62d26 could never be caught by it. No checked-in PostgreSQL CI job enables the general path; external buildfarm coverage is unquantified.
Trust-boundary hardening of logical sequence sync: get_and_validate_seq_info() in src/backend/replication/logical/sequencesync.c reads sequence metadata returned by the publisher. last_value already had explicit NULL handling and was never Assert-only; the Assert-only fields were is_called, page_lsn, and the sequence type/start/increment/min/max/cycle. A broken or malicious publisher returning NULL (or an out-of-range index) there crashes assert builds or feeds garbage into sequence state. PR Validate remote sequence data in sequencesync worker #64 hardens those fields and, more importantly, range-checks seqidx before list_nth(). This is trust-boundary hardening against a broken/malicious publisher — not evidence of an organically reachable corruption bug.
The backup-comparison oracle (pg_combinebackup/t/002_compare_backups.pl) compares pg_dumpall output only — unquestionably blind to stale VM/FSM bits and index corruption. This is one contributing oracle gap in the layers that let ed62d26 through, not the sole reason it survived.
Priorities
P0 means fast, continuously executable signal — not the largest architectural investment. It is what gives us a running detector this week.
Targeted "kill tests" that deliberately recreate the defect (stale VM bits, unregistered blocks) and prove each oracle actually fails on it — otherwise a green oracle proves nothing.
Full physical full-vs-incremental backup differential harness under a concurrent workload (restore + replay to a common target LSN, AM/fork-aware normalization, plus pg_amcheck / pg_visibility) — Physical full-vs-incremental backup differential harness #74.
Large crash / state matrices: wal_level-transition × crash matrix for logicalctl + WAL summarizer fast-forward edges (a passing incremental across a wal_level=minimal window = silent data loss).
Adversarial mock replication server feeding malformed responses to walreceiver/tablesync/sequencesync/slotsync and frontends.
postgres_fdw loopback differential harness under divergent remote session state.
Every new oracle in this campaign must ship with two things, or it does not count:
A committed/recorded kill test — a procedure that reintroduces the defect class the oracle guards (e.g. reinstate ed62d26, inject a stale VM bit, drop a block registration) and demonstrates the oracle fires on it. An oracle never shown to fail is not evidence.
Recorded provenance for every reported run: base commit, build flags, GUCs, seed (where applicable), runtime, raw logs, and a minimization procedure for any failure.
Follow-up work on PRs #65, #68, #79, and #80 is addressing this requirement.
Analysis of the last three days of commits (50 commits, Jul 15–17 2026, v19 beta) identified recurring bug classes behind the fixes (unregistered-buffer WAL omissions, summarizer blind spots, deparse round-trip failures, recovery-boundary state machines, unvalidated wire/file input, boundary off-by-ones). A source-verified audit produced this prioritized plan.
Key verified findings
wal_consistency_checkingis structurally blind to visibility-map corruption:rm_maskgets no fork number, soheap_mask()/mask_unused_space()wipes the whole VM bitmap before comparison, andmask_page_hint_bits()clearsPD_ALL_VISIBLE. The stale-VM-bit corruption fixed in ed62d26 could never be caught by it. No checked-in PostgreSQL CI job enables the general path; external buildfarm coverage is unquantified.get_and_validate_seq_info()insrc/backend/replication/logical/sequencesync.creads sequence metadata returned by the publisher.last_valuealready had explicit NULL handling and was never Assert-only; the Assert-only fields wereis_called,page_lsn, and the sequence type/start/increment/min/max/cycle. A broken or malicious publisher returning NULL (or an out-of-range index) there crashes assert builds or feeds garbage into sequence state. PR Validate remote sequence data in sequencesync worker #64 hardens those fields and, more importantly, range-checksseqidxbeforelist_nth(). This is trust-boundary hardening against a broken/malicious publisher — not evidence of an organically reachable corruption bug.pg_combinebackup/t/002_compare_backups.pl) comparespg_dumpalloutput only — unquestionably blind to stale VM/FSM bits and index corruption. This is one contributing oracle gap in the layers that let ed62d26 through, not the sole reason it survived.Priorities
P0 means fast, continuously executable signal — not the largest architectural investment. It is what gives us a running detector this week.
P0 — quick, continuously executable signal
wal_consistency_checkingpath in one measured CI job (record the runtime cost) — Enable wal_consistency_checking coverage in CI #69.P1 — targeted structural fixes
rm_maskand add a VM-specific mask so VM pages are compared meaningfully — Pass fork number through rm_mask and stop masking away VM page contents #72.P2 — large architectural investments
wal_level=minimalwindow = silent data loss).Campaign-level requirement: kill tests + provenance
Every new oracle in this campaign must ship with two things, or it does not count:
Follow-up work on PRs #65, #68, #79, and #80 is addressing this requirement.
Quick wins now being executed (sub-issues below)
Wave 2 / P0 infrastructure now executing:
Backlog (not yet started)