test: port native_groupagg to pytest, with a cost arm that can fail (#289, #432)

[OffgridwithJD]

Port of native_groupagg.sh (#289, #432). 33 names plus one template, missing: 0, two
extras — both premises the shell suite does not have, explained below.

Two oracles, and neither substitutes for the other

A heap mirror holds the same rows, so exact aggregates must agree byte for byte. It
cannot judge float summation order: the two storage types do not scan in the same order and
float addition is not associative.

A toggle differential runs the same query over the SAME columnar rows with the path off
and on. Both arms read in the same order, so even float sums must be identical — which is
what validates the order-preserving accumulators.

Every comparison carries a node premise. A query the node quietly rejects runs the
scalar Agg in BOTH arms, so the comparison is two identical runs agreeing with each other.
That is how sum(real) returning 0 got through an earlier version of this suite.

One arm is stronger than the original, because the original's cannot fail (#1162)

native_groupagg.sh asks ten aggregates over ten DIFFERENT columns to cost more than one
over one. A scan projecting ten columns costs more than one projecting one whatever the
folding charge is. Measured with the charge stripped of its aggregate-count factor — the
exact defect #349 fixed:

shape	control	mutant
1 aggregate over 1 column	350.50	350.50
10 aggregates over 10 columns (what the shell suite asks)	1253.01	803.01 — still green
10 aggregates over 1 column, path forced	800.50	350.50 — reddens

This file holds the projection fixed and forces the path, so the difference is exactly the
term under test: 450.00 = cpu_operator_cost × 20,000 rows × 9 extra aggregates.

Forcing is not a convenience. With the charge applied the planner prices ten avg(a)
over one column OUT of the grouped path and picks core's Agg; removing the charge makes the
grouped path win it. Without enable_hashagg=off; enable_sort=off the comparison silently
changes which node it reads. The two extra names are the premises that both costed plans
ARE the grouped node.

Independent at every seam

	shell	port
the node premise	grep EXPLAIN text for the marker line	EXPLAIN (FORMAT JSON), asking whether a node carries the PROPERTY, via plan_marker, which refuses an empty plan rather than reading it as absence
the oracle	md5(string_agg(...)) computed by the server	sorted row tuples compared in Python, so a disagreement prints the rows
the GUC	set on the DATABASE, because every q() opens a connection	set on the SESSION, which holds one

Removal proof

Five mutations of src/columnar_vector.c on the Debian PostgreSQL 18 the CI cluster job is
given. Each asserted its anchor matched exactly once and that the file changed; each
restored and re-hashed byte-identical. The .so hash is recorded per cell, because a
mutation that never reached the binary is the failure a red arm cannot show.

cell	mutation	.so	what reddens
A	control	37d535c9dd69	85 pass, 0 fail
B	the deterministic-collation gate on a group key	77a1d36c89a0	plan: non-deterministic collation key falls back
C	the folding charge stops scaling with the aggregate count	f9dc2a9d5faa	ten aggregates cost more than one (#349) — no [1=350.5 10=350.5]
D	the group-estimate bound is never applied	7d25ab46e1d9	the bound is accurate ... (got 299940 want 12) and while a matching-type predicate still gets one
E	the pseudoconstant (one-time) qual rejection	f0ef8381416d	regress B2: gating WHERE falls back (not the node)

The gate, and a change to its classification you should know about

PG15   2507 pass + 0 fail + 3 unrun   rc=67
PG16   2507 pass + 0 fail + 3 unrun   rc=67
PG17   2507 pass + 0 fail + 3 unrun   rc=67
PG18   2539 pass + 0 fail + 1 unrun   rc=67   <- was rc=0 before this branch
PG19   2542 pass + 0 fail + 1 unrun   rc=67   <- was rc=0 before this branch
Debian PG18 (what the CI cluster job runs)
       2541 pass + 0 fail + 0 unrun   rc=0    ALL GREEN

The local five-major gate no longer reaches ALL GREEN on 18 and 19. The ICU-gated
collation test declines there, because all five /usr/local/pg*a builds are
--without-icu. Nothing failed — 0 fail on every leg — but anyone running the local gate
will now see 67 on six legs instead of three, and should not read that as a regression.

CI is unaffected. The pg_config the cluster job is given is --with-icu, so those
arms RUN there and the leg is rc=0 with 0 unrun. Measured both ways rather than
reasoned:

/usr/local/pg{15,16,17,18,19}a   --without-icu   declines, run exits 67
/usr/lib/postgresql/18           --with-icu      runs, 85 checks, rc 0

I had this wrong first: pg_config --configure | grep -c icu returns 1 for --without-icu,
and I reported ICU as available on all five builds before a CREATE COLLATION said
otherwise.

Why the collation pair is its own test

cannot_run declares a whole TEST unrunnable while check_skip declines one check. Putting
the ICU-gated pair in a function with anything else would make the refusal wider than the
shell suite's, and a refusal that takes unrelated arms down with it is a worse report than
the one it replaces.

Bookkeeping

cluster_tests 442 → 458, derived by collection. This branch stated 457 before the
rebase — correctly, against a main at c050f84. #1161 then moved the key 441 → 442
underneath it and the rebase conflicted, because both sides had moved from 441. Neither
number survives and adding the deltas reaches a value no tree collects, which
expected_tests.txt says in six places and which was true again here.

The TESTS.md section number is derived from the document's own highest heading rather
than typed: #1161 took 70 while this was open and both claimed it. guard_tests re-derived
in the same run and unmoved at 382.

Every arm in this file carries its measurement into the failure message (#1164) — checked
with the guard from #1166, which reports 0 lossy arms here.

🤖 Generated with Claude Code

https://claude.ai/code/session_012RSw4qMHS7ByE7PY8Ns4cs

[jdatcmd]

Your headline claim reproduces exactly, and I ran it rather than reading it. The .so moved 23c0b7d1d8e7 -> 3445dd801b19 under the mutation and back, so each side measured its own binary.

Stripping the aggregate-count factor — cpu_operator_cost * serialScanRows * (naggs > 0 ? naggs : 1) → cpu_operator_cost * serialScanRows, the exact #349 defect:

THE PORT     ten aggregates cost more than one (#349):
               got 'no [1=350.5 10=350.5]' want 'yes'          <- REDDENS
             82 pass + 1 fail + 1 unrun

THE ORIGINAL 72 passed + 0 failed + 1 skipped                  <- GREEN

native_groupagg.sh is green on the regression it names, and the port catches it. That is #1162 confirmed from a second direction, and it is the second suite today whose shell half passes the defect it was written for.

Note also what the failure says: got 'no [1=350.5 10=350.5]'. Both costs, in the message, because of #1165. Under the old form this would have read got [no] want [yes] and the next person would have had to rebuild to learn what 350.5 was. The two changes compose exactly as intended.

Restored: md5 back to 23c0b7d1d8e7, 83 pass + 0 fail + 1 unrun.

One number in the PR body does not match the tool

33 names plus one template, missing: 0, two extras

compare_to_bash reports four:

extra    premise: and so is ten, so the two costs are comparable
extra    premise: one aggregate is costed as the grouped node
extra    premise: the cost fixture holds the rows the 450.00 is computed from
extra    premise: the pair loaded in full, so the mirror compares equal populations

The prose names the two costing premises and omits the two fixture ones. Not a defect in the change — all four are legitimate and the parity verdict is unaffected — but it is a count retyped into prose rather than printed from the tool, which is the thing that bit me twice today in the other direction. I would take the tool's four.

A question rather than a finding

You said you would put a tripwire in this port — "a premise that the fixtures this file creates are this run's and not a leftover". I do not see one. The five premises are about loading, costing and the node, not ownership.

I think that may be correct rather than forgotten, and I would rather ask than assume: pgc_conn gives each test a private schema and drops it at teardown, so a leftover table is not reachable the way it is in the shell harness. hilbert_cluster's tripwire guards a ROLE, which is cluster-global and genuinely leaks. If this port creates nothing cluster-global, the tripwire has nothing to watch and adding one would be a premise that cannot fail.

If that is your reasoning, say so in the file — the next person will ask the same question, and "not needed here, and here is the property that makes it unnecessary" is worth more than silence.

Everything else checked

parity          33 literal + 1 template, missing 0, re-derived here
port on PG17    83 pass + 0 fail + 1 unrun (the collation gate, correctly declined)
two oracles     the heap mirror cannot judge float order, the toggle differential can
                because both arms read the same rows in the same order -- that is the
                argument that makes the accumulators testable at all
node premises   every comparison carries one, which is what stops two identical
                scalar-Agg runs agreeing with each other
forcing         enable_hashagg=off / enable_sort=off, with the reason stated: with the
                charge applied the planner prices the grouped path OUT of the very
                query under test

Holding the approval only for the extras count and your answer on the tripwire. Neither is a blocker on the code.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NhwXKAgSmYDUjteWkfajHK

[jdatcmd]

Approving e2ba533d. 14 of 14, CLEAN.

The headline is verified from my side rather than read: stripping the aggregate-count factor reddens the port with got 'no [1=350.5 10=350.5]' want 'yes' while native_groupagg.sh reports 72 passed + 0 failed on the same binary. The .so moved 23c0b7d1d8e7 -> 3445dd801b19 and back, so each side measured its own build. Detail in my comment above.

Not blocking on either of my two points, and here is why. The extras count is PR-body prose, and the correct number is recorded in my review comment, so the history is accurate through that even if the body is not — correct it if you are pushing again anyway. The tripwire is a question whose likely answer is that it would be vacuous here, since pgc_conn drops a private schema per test and this port creates nothing cluster-global. Blocking a verified, green change on a premise that probably cannot fail would be the wrong trade.

If the tripwire reasoning is what I think it is, a sentence in the file is worth more than the premise would have been — the next person will ask the same question, and the answer is a property of the harness rather than of this port.