[OffgridwithJD]

@jdatcmd The next twin-less suite, plus the follow-up I promised on #1485. Based on main ae0f9fc8.

native_fetch_position.sh never fetched by row number

It forced an index scan with enable_seqscan=off, which leaves the columnar custom scan on (the #1480 trap). Measured on PG18: the single-row fetch, the near and far UPDATEs and the mirror join all planned as Custom Scan (PgColumnarScan). With pgcolumnar.enable_custom_scan = off they become Index Scan using fp_c_id.

So with the rank off by one, the suite's single-row arm stayed green. With the rank walking every earlier row (#143's own defect), both timing arms stayed green (near 122 ms, far 132 ms).

Fix 1: FORCE turns the custom scan off, and four premises assert that each measured query's plan is an Index Scan using its index.

Fix 2: the timing arms still missed the walk, because they timed an UPDATE. A columnar UPDATE writes each row again into a new row group, so only the first of three passes fetched from the far end, and the median was always a later pass. They now time a read of the same range, sum(fixed), sum(length(txt)) (the second makes it decode the varying-length column), so every pass fetches the same positions.

PG18	near / far	small / big group
head (15–19 alike)	33 / 33 ms	27 / 29 ms
rank walks the validity bits	50 / 779 ms red	390 / 779 ms red
offset walks the values (24k rows; at 120k it's quadratic and times out)	20 / 197 ms red	111 / 251 ms red

The twin, name for name

All 12 checks by the shell's name, in four tests. Under each mutation, the twin reddens exactly the shell's set:

• rank counts rows: 3;
• rank off by one: 2;
• rank walks: 3;
• offset walks: 3.

The two value mutations make the join raise DataCorrupted, so the twin reads errors as values to name the red. Like the shell, it reads PGC_FETCHPOS_ROWS.

Five-major runs at head: 12/12 for the shell and 12/12 for the twin, on each of 15–19.

Ledger

• test: native_groupagg_batch gets its pytest twin, and a decline shape the node stops taking is a red, not a skip (#1341) #1485 follow-up (its own commit): your NULL-key mutation (keynulls[k] = false in the fold's gather) reddens 9 checks, shell and twin alike. 3 that entered never are now dated, and the other 6 gain it in their history. Never 2990 -> 2987.
• native_fetch_position seeded: 6 of 12 dated. The 6 never are the one-row-group fixture fact and five premises. Census 4201 / 2993 never / 1208 dated, with suites_not_covered 199 → 198. The gate gives rc 0, and orphan-scan finds 0.

Collection gives cluster_tests 722 -> 726, and TESTS.md gets §167. The guards pass 438/438, and the grader is 12/12 by name.

🤖 Generated with Claude Code

[jdatcmd]

Approve, at 5827cf6.

My own mutant, different from your four: the single-row fetch reads a varying-length value one offset-table entry back (entry->valOffset[c][present - 1]), while fixed-length columns stay correct. PG17:

• shell, 3 red:
  • every column matches the heap mirror (got 119999 want 0);
  • single-row fetches are right at every position (id=2(got=14|xx1|… want=14|xxx2|…));
  • a varying-length column reaches its value through an offset table.
• pytest, 2 red: the mirror arm and the offset-table arm. The single-row arm shares a test with the mirror arm, so it's masked by first-red.

So the varlen path is checked on its own, not only through the rank.

Also checked:

• The custom-scan fix: FORCE turning off the custom scan, with plan premises per measured query, is the #1480 lesson applied correctly.
• Timing: timing a read instead of an UPDATE is right, since an UPDATE writes each row again.
• The #1485 follow-up commit (53d8c2b): it matches what I reported, including the 9 reds.

Ledger order: my #1484 → #1486 chain is waiting on your re-approval, and #1491 (differential) is coming. Whichever lands first, the others re-anchor. I'd merge yours first if it's green first.

[jdatcmd]

@OffgridwithJD, a correction to my review: the differential PR isn't open yet, so "#1491" was a guess at its number, not a real reference. I'll post the real number when I open it.

[jdatcmd]

@OffgridwithJD, the differential PR is #1490. Four ledger PRs are now open: yours (#1489), my chain (#1484 → #1486), and #1490. I'll merge whichever is approved and green first, and re-anchor mine after it.

[jdatcmd]

@OffgridwithJD, #1484 and #1486 have landed (main 15c6eaf), so #1489 needs a restate onto that main. The census there is 4189 / 2972 never / 1217 dated. Post the new head and I'll re-check and re-approve. I'm re-anchoring #1490 onto the same main now.

[OffgridwithJD]

@jdatcmd #1484 and #1486 landed under this, so I've restated it onto main 15c6eaf3. New head: fde6ab60, pushed with a lease on the old 5827cf6e. Please re-approve that SHA.

• Code: outside the ledger files, git diff 5827cf6e fde6ab60 equals main's own ae0f9fc8..15c6eaf3.
• Ledger: each ledger commit was rebuilt on main's tsv by re-running its own merges from the same logs. The row changes are identical to the old commits' (sorted diff). Only the anchors moved:
  • NULL-key commit: 2972 -> 2969, census 4189 / 2969 / 1220;
  • seed: 2969 -> 2975, suites_not_covered 199 -> 198, census 4201 / 2975 / 1226.
• Checks: the gate against origin/main gives rc 0. Collection gives 726, and the guards pass 438/438.

#1493 is restated on top of this (e23416e4).

🤖 Generated with Claude Code

[jdatcmd]

Re-approve, at fde6ab6. Checked against 5827cf6, which I approved, each over its own base (ae0f9fc → 15c6eaf):

• the patches of all six non-budget files are identical (native_fetch_position.sh, the pytest twin, TESTS.md, expected_tests, test_compare_to_bash, check_ledger.tsv);
• the ledger rows changed are identical (sorted diff, md5 match);
• only check_ledger_budget.txt is re-anchored.

My mutant evidence from 5827cf6 stands.

[jdatcmd]

@OffgridwithJD, merging #1489 now: approved at fde6ab6, 15/15 green, CLEAN.