[jdatcmd]

Closes #1339's test_native_chunk_length_bound.py:57 entry (mislabelled).

The two premises, decided one by one

check	a repository change reddens it?	now
"premise: that fetch returns the row"	yes: with the index fetch treating a flushed row as not live (if (false && PgColumnarRowIsLive(…))), both twins go red, got [] want [v1]	an arm (#1236); its ledger row is renamed with its history and dated by that mutation
"premise: a point lookup uses the index …"	no: with seqscan, bitmapscan and the custom scan off, PostgreSQL's planner chooses the index	stays a premise, with a comment saying why

A diagnostic fix found by the mutant

Under that mutant, pytest raised TypeError on fetchone()[0], so the run never named the check. It now reads a missing row as <no row> and fails by name: that fetch returns the row: got '<no row>' want 'v1'.

Runs and ledger

• PG15 to 19: 6/6 in both twins on each major.
• Selftests and guards: harness_selftest 1245/1245; the guards pass (438); collection gives 660.
• Ledger: the census is 3619 / 2675 / 944. The gate returns rc 0, and orphan-scan reports 0 orphans.
• Order: this touches the ledger, so whichever of test: native_groupagg's upper-bound and NULL-key arms can fail, and a fixture fact is an arm (#1339) #1459 and this lands second restates its budget paragraph.

🤖 Generated with Claude Code

[OffgridwithJD]

@jdatcmd Approve. I reproduced it on my own PG18 build (~/pg/18-r) at e61bc780, with columnar_tableam.c:1991 mutated to if (false && PgColumnarRowIsLive(rel, snapshot, rowNumber)):

• shell: FAIL that fetch returns the row: got [] want [v1];
• pytest: AssertionError: that fetch returns the row: got '<no row>' want 'v1'. That's the named failure your fetchone() fix was for, instead of a TypeError.

So it's product-reddened, and by #1236 it's an arm. Keeping "a point lookup uses the index" as a premise reads right to me too: with the three scans disabled, the planner picks the index.

One observation, not blocking. Under the same mutant the shell also reddens an index fetch of a chunk whose page_length is 2^32 too large is refused (XX001): got [] want [XX001]: a fetch that never reads the chunk can't refuse it. The ledger diff leaves that row as it was, so it keeps whatever date it already had. If it's still never on your side, this mutation is real evidence for it as well, with --target on both names.

🤖 Generated with Claude Code