[OffgridwithJD]

#1341's remaining twin-less suites: pg_dump_roundtrip.sh had no pytest twin. This PR adds one, every check by the shell's name, seeds the suite into the ledger, and fixes two arms that couldn't fail as their names claim.

Stacked on #1457, at the top of my chain. This branch is #1457's head plus two commits.

What changes

• test/pytest/test_pg_dump_roundtrip.py, the twin: three tests.
  • The source: a private database holds a columnar table with data, an option, an index and a projection. A second table declares a sort_by naming columns after a dropped one (Add segmentby-style clustering / data-skipping to close the selective-query gap (~1000× behind TimescaleDB) #288).
  • The round trips: the source is dumped as plain SQL and as a custom archive, each restored into a fresh database with the cluster's own pg_dump, pg_restore and psql.
  • compare_to_bash.py grades it as covering all 25 names (40 checks over the two formats), and it joins COMPLETE.
• "restored index answers a point lookup" didn't test the index. The lookup disables seqscan and bitmapscan, but the columnar scan is neither.
  • Measured: with the index dropped from the restored database, the lookup still answered 12345, and the suite stayed 36/36.
  • The fix: a premise now asserts that the lookup's plan uses dt_id_idx.
• "restored sort_by resolves and applies" didn't test the order. It checked the row count after vacuum_sorted, which is 20000 whatever columns it sorted on.
  • Measured: with the sort keys replaced by column 1, the suite stayed 36/36.
  • The fix: the arm now counts (host, ts) inversions in scan order, which must be 0, with a premise that the restored table has some before the call. The twin runs these readers with parallel workers off, as the shell's cluster does.
• Ledger: pg_dump_roundtrip is seeded with 40 rows from five-major runs, and 16 of the 40 rows dated. suites_not_covered goes 213 → 212, and the census is 3755 + 40 = 3795 rows, 2755 + 24 = 2779 never and 1000 + 16 = 1016 dated, matching the tsv. The gate gives rc=0 against origin/main.

Red first

Each mutation was run one at a time on PG18, through both twins, with the .so md5 printed every time. The SQL mutations edit pgcolumnar--1.0-alpha5.sql, which each suite's CREATE EXTENSION reads.

mutation	pg_dump_roundtrip.sh	test_pg_dump_roundtrip.py	the arms that went red
none (the head)	40/40	40/40	none
pgcolumnar.options not registered with pg_extension_config_dump	34/40	2 of 3 tests fail	both formats' options and declared sort_by: got [<none>] want [fast]
pgcolumnar.projection_declaration not registered	32/40	2 fail	both formats' declaration and rebuild arms: got [0] want [1]
rebuild_projections() skips missing projections (NOT EXISTS → EXISTS)	33/40	3 fail	the rebuild arms
drop_projection keeps its declaration	32/40	3 fail	the drop arm, got [2] want [1], and every declaration count after it
vacuum_sorted sorts on column 1	38/40 (36/36 before this PR)	2 fail	both formats' restored sort_by resolves and applies: got [20000|2000] want [20000|0]
harness: the restored database loses its index	38/40 (36/36 before this PR)	—	both formats' premise: the point lookup takes the restored index

Never red (24):

• the dump and restore exit codes, and the dump's columnar AM;
• the access method, the row count and the checksum;
• the index premise and its lookup;
• the pinned loss of projection storage (Projections are lost across pg_dump / restore #266);
• the inversion premise;
• the second rebuild's no-op;
• the source's own premises.

Runs

major	pg_dump_roundtrip.sh	test_pg_dump_roundtrip.py
15	40/40	40/40
16	40/40	40/40
17	40/40	40/40
18	40/40	40/40
19	40/40	40/40

Also measured: the guard half (438 tests), harness_selftest 1245/1245 and docs_style. cluster_tests goes 677 → 680 by collection, and TESTS.md gets §150.

🤖 Generated with Claude Code

[jdatcmd]

Approving 4b8447f.

Measured on PG17: pg_dump_roundtrip.sh 40/40; test_pg_dump_roundtrip.py 40 checks over 3 tests.

Your index claim, with the harness mutation run myself: DROP INDEX IF EXISTS dt_id_idx on the restored database just before the premise, in both twins. Both formats' premise: the point lookup takes the restored index go red, got [0] want [1], in each twin. The lookup arm after it still answers 12345, which is why the premise has to be there: the columnar scan answers without the index, as you measured.

I took the SQL and sort_by mutants from your table. This sits on top of the #1450 → #1457 stack I approved, and the stack's restate covers it.

[jdatcmd]

Re-approving 1da9bbf, 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.