[OffgridwithJD]

#1341, the twin-less suites (the second of that item's list): truncate_cleanup.sh had no pytest twin. This PR adds one, every check by the shell's name, and seeds the suite into the ledger. The shell needed no change. Each of its arms already goes red under a mutation of the path it names. Its comments record two arms that once passed on main and were fixed in review.

Stacked on #1452, at the top of my chain (#1444 → #1446 → #1448 → #1450 → #1452). This branch is #1452's head plus two commits.

What changes

• test/pytest/test_truncate_cleanup.py, the twin. It has six tests in a private database (pgc_own_db), since the snapshot counts every pgcolumnar catalog row, and the shared database holds every other test's.
  • It keeps the shell's two path distinctions:
    • The repetition test truncates a table created in an earlier statement, so every TRUNCATE takes the transactional path.
    • The in-place test creates its table in the same transaction, so the TRUNCATE takes nontransactional_truncate.
  • compare_to_bash.py grades it as covering all 25 names, and it joins COMPLETE.
• Ledger: truncate_cleanup is seeded with 25 rows from five-major runs, and 16 of the 25 rows dated. suites_not_covered goes 218 → 217, and the census is 3647 + 25 = 3672 rows, 2687 + 9 = 2696 never and 960 + 16 = 976 dated, matching the tsv. The gate gives rc=0 against origin/main.

Red first

Each mutation of src/columnar_tableam.c was run one at a time on PG18, through both twins, with the .so md5 printed every time.

mutation	truncate_cleanup.sh	test_truncate_cleanup.py	the arms that went red
none (the head)	25/25	25/25	none
a rewrite no longer deletes the retired storage's rows (pgcolumnar_delete_storage_tree)	18/25	3 of 6 tests fail	every leak arm: got [1/0/1/2/4/2/0] want [0/0/0/0/0/0/0], ten cycles reaching 10/0/10/20/40/20/0
a rewrite no longer drops the stale write state	24/25	1 fails	INSERT, TRUNCATE, INSERT in one transaction …: got [rc=0 -1..-1 n=0], a committed empty table
the in-place truncate skips a projection's storage (:1323)	17/25	1 fails	the in-place transaction rolls back on row_group_pkey, and every arm after it goes red
a storage-tree delete skips the projections' storages (:1221)	24/25	1 fails	DROP of a loaded projected table leaves nothing: got [2/0/2/6/12/6/0]

Never red (9):

• the premises that each fixture holds rows or metadata;
• the surviving projection declaration;
• the empty table after TRUNCATE;
• the rewrite that keeps every row.

Runs

major	truncate_cleanup.sh	test_truncate_cleanup.py
15	25/25	25/25
16	25/25	25/25
17	25/25	25/25
18	25/25	25/25
19	25/25	25/25

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

🤖 Generated with Claude Code

[jdatcmd]

Approving d7cd0fe.

Measured on PG17: truncate_cleanup.sh 25/25; test_truncate_cleanup.py 25 checks over 6 tests. The tsv at this head is 3672 / 2696 / 976, matching its budget.

Your first mutant, run myself: the rewrite's pgcolumnar_delete_storage_tree(PgColumnarStorageId(rel)) removed. The shell is 18/25: every leak arm, starting with TRUNCATE returns the catalog to the empty baseline: got [1/0/1/2/4/2/0], and the projection arm got [2] want [0]. In pytest, 3 of 6 tests fail, ten cycles reaching 10/0/10/20/40/20/0. Your table says the same.

A note on the shell, not a blocker: under that mutant, the later shell arms' want is not zero (for example want [3/0/3/6/12/6/0]). They compare against a snapshot taken after the earlier arms' leak, so they measure the leak since the snapshot. They're still red. And pytest's private database (pgc_own_db) gives every test an absolute baseline, which is the stronger form.

I took the other three mutants from your table.

[jdatcmd]

Re-approving 50a8c31, 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.