[OffgridwithJD]

@jdatcmd This closes three gaps I left open in #1493, #1503 and #1502.

#359 and #433: the arms were fine, my mutants weren't

native_fetch_cache's #359 ratio and native_fetch_bigcap's two #433 ratios went into the ledger as never, because the mutations I tried didn't move them. Those mutations weren't the defects. Restoring each pre-fix behaviour as its own mutant (from a917034 and 08c4e38) reddens the arms as they stand. The suites don't change.

mutant (PG18)	arm	head	mutant
#359: no column released over the cap, whole entry dropped once over it	five columns ÷ four, bound 12×	65 → 470 ms (7.2×) on PG18; 6.3–7.2× across 15–19	68 → 1956 ms (29×), and 138 → 2107 on a second run
#433: each entry reads its group whole, group over the cap dropped after every fetch	narrow, 10 rows ÷ 1, bound 3×	5547 → 5628 buffers	10788 → 58074
same	medium, 10 rows ÷ 1, bound 3×	5587 → 5668	10828 → 58699

The twins redden the same names. In #1493 I wrote that "the cliff hits even one projected column". That was my dropall mutant, not #359's code.

maintenance_crash: the index is now held to a scan

Each "by scan and by index" arm compares the state after a crash with the state before it, both read through mc_id. An index that was already wrong agrees with itself, so with pgcolumnar_index_fetch_tuple finding no row, the suite as on main passes 25/25 (source fingerprint checked to differ from head).

After each recovery, both crashes and all four functions, the suite now also checks after a crash with <f> <uncommitted|committed>, the index reads the rows the scan reads. That's eight arms, in the shell and the twin. Under the same mutant all eight go red, with identical names on both sides, and they're green at head on 15–19. TESTS.md §123 says so.

Ledger

4388 → 4396 rows, never 3058 → 3055, dated 1330 → 1341. The 8 new arms are dated by the no-row mutant, the two #433 arms by the #433 mutant, and the #359 ratio by the #359 one. Head runs on each of 15–19: maintenance_crash 33/33, native_fetch_bigcap 15/15, native_fetch_cache 26/26. The gate returns rc 0 (ceiling 190 → 190), and orphan-scan finds 0 per suite. The grader passes the pair, and the NO_CLUSTER guards pass 438/438.

🤖 Generated with Claude Code

[jdatcmd]

Approve, at b2368c9.

My own mutant, the one that left maintenance_crash green on #1502: the deferred decode (pgcolumnar_slot_getsomeattrs) returns column 1 as NULL on every 7th row number, so the index's reading is wrong both before and after the crash. PG17:

• shell: all 8 new arms red, "after a crash with <uncommitted|committed>, the index reads the rows the scan reads" (5400/… hash mismatches), 25 + 8 = 33;
• pytest: red on the first, compact_rewrite uncommitted, with the rest masked by first-red.

So the before/after design now has an independent reference: a fault present on both sides no longer cancels out. That closes the gap I raised.

On #359 and #433: restoring each fix's own pre-fix behaviour as the mutant is the right method. A mutant that isn't the defect proves nothing about the arm written for it. Your correction of the "the cliff hits even one projected column" note is noted.

The ledger: reads 4388 → 4396 / 3058 → 3055 / 1330 → 1341, consistent with 8 new dated rows and 3 newly dated.

[jdatcmd]

@OffgridwithJD, merging #1511 now: approved at b2368c9, 15/15 green, CLEAN.