[OffgridwithJD]

#1341, the twin-less suites (the first of that item's list): fk_referencing.sh had no pytest twin. This PR adds one, every check by the shell's name, seeds the suite into the ledger, and adds one control the shell was missing.

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

What changes

• test/pytest/test_fk_referencing.py, the twin. It has five tests in a private schema on the shared cluster.
  • It checks both routes into the trap: a constraint created against a columnar table, and a referenced table converted to columnar, including a partitioned parent.
  • It checks both directions: only the referenced side is refused.
  • It keeps the shell's PG17 split. From 17 an unreferenced partitioned table converts; before 17 core refuses it by its own message.
  • compare_to_bash.py grades it as covering all 28 names (27 checks on 17+, and the pre-17 branch's own), and it joins COMPLETE.
• A missing over-rejection control. "converting back to heap is unaffected" ran on a table with no foreign key, so it couldn't see a conversion guard that refused every SET ACCESS METHOD on a referenced table, whatever the target.
  • Measured: with the guard's columnar-target test removed, the suite stayed 26/26.
  • The fix: a new arm, an FK-referenced table may still be set to a row store, runs SET ACCESS METHOD heap on the referenced table itself. Both twins fail it under that mutant.
• Ledger: fk_referencing is seeded with 28 rows from five-major runs, and 17 of the 28 rows dated. suites_not_covered goes 219 → 218, and the census is 3612 + 28 = 3640 rows, 2671 + 11 = 2682 never and 941 + 17 = 958 dated, matching the tsv. The gate gives rc=0 against origin/main.

I also probed a route the suite doesn't take: ATTACH PARTITION of an existing columnar table under an FK-referenced parent. It's refused by the same constraint hook (core clones the constraint for the new partition), so it isn't a gap and I added no arm.

Red first

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

mutation	fk_referencing.sh	test_fk_referencing.py	the arms that went red
none (the head)	27/27	27/27	none
the referenced-side refusal removed	22/27	2 of 5 tests fail	sections 1, 2 and 7's columnar partition
the guard keyed on the referencing table (conrelid for confrelid)	19/27	3 fail	the same, plus section 3: a columnar table referencing heap is now refused
the conversion refusal removed	19/27	2 fail	section 5 (refused, the message, still heap, child writable, the helper) and section 7's parent conversion
the conversion refused whatever the target	26/27 (27/27 before this PR's arm)	1 fails	an FK-referenced table may still be set to a row store

Never red (11):

• the over-rejection controls that no single guard reaches: another constraint, a heap-to-heap key, an unreferenced conversion, an unrelated ALTER, a conversion back to heap, the referencing side, and the partitioned control on either side of 17;
• the primary key's own arms.

Runs

major	fk_referencing.sh	test_fk_referencing.py
15	26/26	26/26
16	26/26	26/26
17	27/27	27/27
18	27/27	27/27
19	27/27	27/27

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

🤖 Generated with Claude Code

[jdatcmd]

Approving b32d190.

Measured on PG17: fk_referencing.sh 27/27, and test_fk_referencing.py 27 checks over 5 tests. The census at this head (3640 / 2682 / 958) matches the budget, and suites_not_covered is 218.

Your new over-rejection arm, with my own mutant. I replaced the target test in the conversion guard (if (!pgcolumnar_am_is_columnar(…)) continue;) with nothing, so every SET ACCESS METHOD on a referenced table is refused, heap included. Only the new arm goes red, in both twins: an FK-referenced table may still be set to a row store, got [no (ERROR: cannot convert table "fk_conv_parent" to columnar storage …)]. So the control you added is the one that sees over-rejection, as the PR says.

I took the other three guard mutants from your table.

[jdatcmd]

@OffgridwithJD, a correction to my approval of b32d190. I quoted the census as 3640 / 2682 / 958, copied from your description, not measured. The tsv at this head is 3647 / 2687 / 960, and the budget's checks_never_observed_red is 2687, so the head agrees with itself. The difference, 7 rows (5 never and 2 dated), is exactly #1449's rows. So the description's numbers predate your rebase over #1449. The approval stands. When you restate the stack onto 0edb5ae, the description's census line will need updating.

[jdatcmd]

Re-approving 4ee6e1f, 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.