[OffgridwithJD]

@jdatcmd The fourth #1339 custom-scan audit entry, done as a twin PR because native_fetch_bigcap.sh had none. Stacked on #1502 (#1500 → #1502 → this). This PR's own commits are the top two.

What changed

• FORCE_INDEX also turns the custom scan off.
• Two new premises, in both twins: the narrow (sum(tag)) and medium (m1 || m2 || m3) projections are fetched through an index scan. Before this, only the payload query's plan was asserted.

Both projections plan as Index Scans today (measured), so these guard against a planner change. They aren't a red-first fix, and I'm not claiming one.

Two things I measured and left alone

• "the fetched rows are the right rows" compares an unforced WHERE id BETWEEN 1 AND 10 read with an ORDER BY id LIMIT 10 read. Those take different paths, so with the deferred decode reading tag as NULL on every 7th row number (your test: native_index gets its pytest twin, and every lookup fetches through the index (#1341, #1339) #1499 mutant, on tag), it's red, in the old suite and in both twins now. I first forced its left side through the index too. That made both sides corrupt the same way, and the arm went green under the mutant, so I reverted it. It stays as it was.
• The two Row groups above the 32 MB fetch-cache cap have a 100 percent miss rate: a full group re-read per fetched row #433 ratios don't move when the cache misses every lookup, or when crossing the cap drops every column (narrow: 5547 → 5664 buffers for 10 rows). Those mutations re-read only the projected columns, while Row groups above the 32 MB fetch-cache cap have a 100 percent miss rate: a full group re-read per fetched row #433's own regression re-read the group's raw bytes per fetch, the 10× the payload arm shows (5547 → 52203). I have no single-gate mutation for that here, so they stay never.

The twin

All 15 checks by the shell's name, in two tests. It sums buffers the way the shell's awk does, and mirrors check_ratio (two-place rounding, a zero side refused). Under the decode mutation it reddens exactly the shell's arm. Five-major runs at head: 15/15 for the shell and 15/15 for the twin, on each of 15–19.

Ledger

Census 4347 / 3031 never / 1316 dated (on #1502's 4332 / 3017 / 1315), with suites_not_covered 193 → 192. One arm is dated (the right rows). The gate gives rc 0. Collection gives cluster_tests 742 -> 744, and TESTS.md gets §173. The guards pass 438/438.

🤖 Generated with Claude Code

[jdatcmd]

Approve, at 45a8bfa (its own commits 6bc09e0 and 45a8bfa, on #1502).

My own mutant, different from your tag one: once a column has gone over the fetch cache cap (entry->overflow[c]), the single-row fetch returns it as NULL (nulls[c] = entry->overflow[c]). payload is exactly that column here (#359). PG17:

• shell: the fetched rows are the right rows: got [18e412d5…] want [8f6d77b4…];
• pytest: the same hashes.

So that arm sees an over-cap column going wrong, not only a fitting one.

Your two "left alone" notes:

• Not forcing the right-rows arm's left side: right, and well measured. Forcing both sides through the same path makes a shared fault cancel out, the same trap maintenance_crash has by design.
• The #433 ratios that no single-gate mutation moves: keeping them never is the honest call.

The two new plan premises are guards, not red-first fixes, as you say.

[jdatcmd]

@OffgridwithJD, merging #1503 now: approved at 45a8bfa, 15/15 green, CLEAN.