[OffgridwithJD]

@jdatcmd The second #1339 custom-scan audit entry. Stacked on #1499 (#1497 → #1498 → #1499 → this). This PR's own commits are the top two.

The shell's path arms took one path, not four

native_delete_visibility_paths.sh set enable_seqscan / enable_indexonlyscan and trusted its arm names. None of the enable_* GUCs governs Custom Scan (PgColumnarScan), so the index / bitmap and index-only arms ran the columnar custom scan, the same path as the sequential arm. The pytest twin has forced each path with pgcolumnar.enable_custom_scan = off and asserted the node from the start; its docstring reported the shell's gap. The shell now does the same, under the twin's premise names, and gains the twin's three other checks (the 5000 rows, more than one row group, the rolled-back row). The twins now match one for one, with 15 literal matches.

Red first:

mutation (columnar_reader.c)	old shell	new shell = twin
pgcolumnar_fetch_row ignores the delete vector	2 red; "index / bitmap scan" and "index-only scan" green	4 red: those two, the deleted row via the index, and the in-transaction read
the row-at-a-time scan reads a deleted row as live	(not run)	2 red: the sequential arm and the #1394 arm

The liveness-cache, batch-scan and buffered-delete mutations redden nothing here. The aggregate arm reads the vectorized count, and the in-transaction read is served through the fetch.

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

Ledger

Census 4330 / 3019 never / 1311 dated (on #1499's 4323 / 3017 / 1306):

• seven new rows, all never;
• five arms that entered never are now dated;
• the A DELETE whose qual deletes another row of the same columnar table fails: 'attempted to update invisible tuple' #1394 arm gains the scan mutation in its history.

The gate gives rc 0, and orphan-scan finds 0. No tests are added, so collection is unchanged.

🤖 Generated with Claude Code

[jdatcmd]

Approve, at 29c77e5 (its own commits d9d3ecf and 29c77e5, on #1499). It also closes the twin gap I noted on #1339: the shell now has "the rolled-back delete left the row in place".

My own mutant, different from your two: PgColumnarMarkRowDeleted marks the neighbouring row (rowNumber + 1), so the live count barely moves and only a specific-row arm can see it. PG17:

• shell, 4 red:
  • a deleted row is invisible via the index (got 1 want 0);
  • a live row is visible via the index (got 0 want 1);
  • the rolled-back delete left the row in place (got 0 want 1);
  • the #1394 arm (XX000|20|210).
• pytest: red, with the rest masked by first-red.

A finding, not blocking, and not this PR's: skipping the visibility-map clear on delete (PgColumnarVMClearForRow in columnar_delete_vector.c) leaves both twins 15/15 green. The function's own comment says why: the clear is a no-op unless a vacuum had marked the block visible, and this fixture never vacuums before it deletes. So the index-only arm always fetches, and the gap-28 bug, where an index-only scan trusts a stale all-visible bit, can't show here. A VACUUM t before the DELETE (or a second index-only arm after a vacuum) would make it reachable. I can take that as a follow-up.

[jdatcmd]

@OffgridwithJD, merging #1500 now: approved at 29c77e5, 15/15 green, CLEAN.