[OffgridwithJD]

@jdatcmd The first of the #1339 custom-scan audit entries I posted, done as a twin PR because native_index.sh had none. Stacked on #1498 (#1496 → #1497 → #1498 → this). This PR's own commits are the top two.

native_index.sh's range aggregate never fetched by row number

iscan() forced the index path with enable_seqscan=off alone, which leaves the columnar custom scan on. Measured on PG18: "index range aggregate" (id BETWEEN 100 AND 400) planned as Custom Scan (PgColumnarScan). Red first, with two mutations of pgcolumnar_index_fetch_tuple:

mutation	old suite	new suite and twin
the neighbouring row fetched (rowNumber + 1)	5 red; "index range aggregate" green	6 red, including the range aggregate
no row found	5 red; "index range aggregate" green	6 red, including the range aggregate

Fix: iscan now also sets enable_bitmapscan, enable_indexonlyscan and pgcolumnar.enable_custom_scan off, so every lookup is an Index Scan that fetches. Four premises assert that plan through n_pkey, using lib.sh's pgc_uses_row_fetch.

The twin

All 13 checks by the shell's name, in two tests. Under both mutations it reddens exactly the shell's set. Five-major runs at head: 13/13 for the shell and 13/13 for the twin, on each of 15–19.

Ledger

Census 4323 / 3017 never / 1306 dated (on #1498's 4310 / 3010 / 1300), with suites_not_covered 194 → 193. 6 of the 13 checks are dated. The gate gives rc 0, and orphan-scan finds 0. 7 arrive never:

• the four index-path premises;
• the row count;
• the lookup miss;
• the unique index admitting a new key.

Collection gives cluster_tests 740 -> 742, and TESTS.md gets §172. The grader shows 9 literal + 1 template match with 0 missing, and the guards pass 438/438.

🤖 Generated with Claude Code

[jdatcmd]

Approve, at 0c4edf8 (its own commits 7cd05c4 and 0c4edf8, on #1498).

My own mutant, different from your two: the deferred decode (pgcolumnar_slot_getsomeattrs, the #157 path an index fetch hands its slot to) returns k as NULL on every 7th row number. PG17:

• shell: index range aggregate: got [301|644140|row-100|row-400] want [301|752500|row-100|row-400];
• pytest: the same.

That's the arm your custom-scan fix moved onto the fetch path, so the fix is what makes it see this.

My own miss, for the record: my first attempt put the mutant at the end of pgcolumnar_index_fetch_tuple and stayed green. The slot is deferred there, so the later decode overwrote what I set: an inert mutant, not a gap in the suite. Moving it into getsomeattrs is what reached the runtime.

[jdatcmd]

@OffgridwithJD, merging #1499 now: approved at 0c4edf8, 15/15 green, CLEAN.