[OffgridwithJD]

@jdatcmd Item 74's next twin-less suite: native_groupagg_batch.sh gets test_native_groupagg_batch.py, and the suite is seeded in the ledger.

The twin, red first and name for name

All 69 checks by the shell's name, in eight tests. Under each of twelve mutations of the grouped fold, the twin reddens exactly the shell's set. I read that with a scratch runner that records every red and carries on, which also answers your masking note on #1482: the full set is compared, not only each test's first red.

mutation (columnar_vector.c)	reds, shell = twin
the grouped fold never called (the removal proof)	12, every work-done arm
float8 admitted as a bitwise key	2, the -0.0/0.0 arms
delete mask ignored	5
a skipped vector's present slots not consumed	2
no scan key applied per row	4
by-value gate dropped (text key reaches the gather)	2
exactness gate dropped (<> folded)	2
min/max admitted as fold kinds	1
expression-key gate dropped	2
partial node without the shared counter	2
ANALYZE prints the prediction (#602's shape)	1
grouped path refuses a text key	1

Two of these make the columnar query error (by-value and expression-key). The shell names those reds through pgc_fail and an empty fold value, while the first draft of the twin raised and named nothing. Its helpers now read an error as a value.

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

Two shell changes

• The decline arms can no longer skip. When the grouped node wasn't planned for a decline shape, the arm read check_skip. That never fired on 15–19, and with the node gone the gate under test is unreachable, so the skip was a silent pass. Red first, with the planner refusing a text key:
  • old suite: 68 passed + 0 failed + 1 skipped, rc 0;
  • new suite: text key: the fold declined is red, and the twin agrees.
• A rename. "skipped vectors: four payload columns all stay in step" read only the fold's yes/no. The next arm checks the sums, and only the fold-removal mutation reddened this one. It's now "skipped vectors: the fold ran on the four-payload arm". The suite had no ledger rows, so nothing else is renamed.

I also checked the add-column answer arm, which wraps the grouped query in an outer sum, the very shape the suite warns about for float8. Its plan does keep the grouped node (row path, "Batch Fold: no"), so the arm is sound.

Ledger

Census 4171 / 2980 never / 1191 dated (on main f1fa632d), with suites_not_covered 201 → 200. 31 of the 69 checks are dated. gate --against origin/main gives rc 0, and orphan-scan finds 0. 38 arrive never:

• 16 premises and the 2 float8 fixture facts;
• the 8 "grouped node is planned" arms and 2 parallel plan arms, which no fold mutation reaches;
• 7 heap-mirror oracles (plain, two keys, float8, count(*), timestamp, date, min/max) that none of these mutations moves;
• the <> count, read by an ungrouped count(*);
• the add-column prediction and answer.

The mutant logs come from the tree just before the rebase over #1479, which changed only lib.sh's stamp key.

Collection gives cluster_tests 710 -> 718, and TESTS.md gets §165. The guards pass 438/438 and the grader 40/40.

🤖 Generated with Claude Code

[jdatcmd]

Approve, at 831628d.

My own mutant, different from your twelve: in the batch fold's gather (columnar_vector.c, the loop before the pgcolumnar_groupagg_lookup call at :6157), drop the NULL flag: keynulls[k] = false. That folds the NULL-key group into k = 0 on the batch path only; the row path at :6277 keeps it. PG17:

twin	reds
shell	9: plain, filtered, two keys, count(*) and deletes against the heap mirror; toggle-differential plain, filtered and two keys; parallel against the heap mirror
pytest	4: plain, deletes, toggle-differential plain, parallel (the rest masked by first-red; it's the same set, which your carry-on runner showed)

One thing for the ledger, not blocking. Three of those reds are rows this PR enters as never: plain: answers match the heap mirror, two keys: answers match the heap mirror and count(*): answers match the heap mirror. Your description says none of your mutations moves the seven heap-mirror oracles; this one moves three of them. If you want, merge a log from this mutant to date them (a follow-up is fine too).

Also checked: the three-dot diff holds only the 7 files in your stat. The check_skip → red change for an unplanned decline shape is the right direction: a gate that can't be reached is a red.

[OffgridwithJD]

@jdatcmd Thanks, your NULL-key mutant is a good one. I reproduced it on PG18 in my parity harness. keynulls[k] = false in the fold's gather gives 9 shell reds, and the soft-expect twin reddens the same 9 by name. That includes plain, two keys and count(*) against the heap mirror, which this PR enters as never.

#1484 and #1486 both touch the ledger, so this PR (and #1487 on top of it) needs a restate when they land. I'll merge this mutant's log in that restate, so those three rows arrive dated. I'll also correct the description's "seven heap-mirror oracles that none of these mutations moves" to four, and post the new heads for re-approval.

🤖 Generated with Claude Code

[jdatcmd]

@OffgridwithJD, merging #1485 now: approved at 831628d, 15/15 green, CLEAN. #1487 follows once it's green.

[jdatcmd]

@OffgridwithJD, a note on order: I merged #1485 before #1484 and #1486, because #1487 is stacked on it and merging mine first would have made you restate both. So #1485 needs no restate. I'll re-anchor #1484 and #1486 on 2c661ed myself and post their new heads.

The three heap-mirror rows (plain, two keys, count(*)) are still never on main. Two options; either works for me:

• fold the NULL-key mutant's log into test: native_fetch_projection gets its pytest twin, and its source arms read code, not the comment that says the call was removed (#1341) #1487's restate, if test: native_fetch_projection gets its pytest twin, and its source arms read code, not the comment that says the call was removed (#1341) #1487 needs one anyway;
• send a small follow-up PR that only merges that log and fixes the census.

#1487 is approved at 53543d7, and I'll merge it once its checks are green.