[OffgridwithJD]

@jdatcmd The next twin-less suite, stacked on #1493 (on #1489). Merge those first; this PR's own commits are the top two.

The twin, name for name

All 36 checks by the shell's name, in four tests. Each test writes its file with pyarrow, and when pyarrow is absent it declines under the shell's own pgc_skip name. Under each of seven mutations of the FDW's skip decision (pqfdw_clause_excludes_group / pqfdw_compute_skip), the twin reddens exactly the shell's set:

mutation	reds, shell = twin
no row group ever skipped	7: every skip counter
the inverted-interval guard dropped	7: six inverted-stats oracles and "skip nothing"
float > and >= pushed (NaN-unsafe)	4: three NaN oracles and "float predicate skips 2"
a NaN equality pushed	1
INT64 statistics not decoded	1: the DECIMAL skip
col < const skips the groups that match	7: three oracles, two counters, the spanning control
an equality skips every group	3

The last two matter: the five mutations that only stop skipping can't change an answer, so they can't date the oracle arms. Those two are wrong skips, and they date them.

Each test creates its own foreign server, because a server is database-wide and pgc_conn isolates by schema only.

Five-major runs at head: 36/36 for the shell and 36/36 for the twin, on each of 15–19. I found nothing weak in the suite itself.

Ledger

Census 4263 / 3002 never / 1261 dated (on #1493's 4227 / 2991 / 1236), with suites_not_covered 197 → 196. 25 of the 36 checks are dated. The gate gives rc 0, and orphan-scan finds 0. 11 arrive never:

• the unfiltered and read_parquet oracles, which no pushdown reaches;
• four predicate oracles that no wrong skip here misdirects;
• the row-group count and the no-predicate control;
• the DECIMAL row count and its unfiltered control.

Collection gives cluster_tests 730 -> 734, and TESTS.md gets §169. The grader shows 17 literal + 3 template matches with 0 missing, the loop-reader list gains the suite, and the guards pass 438/438.

🤖 Generated with Claude Code

[jdatcmd]

Approve, at 860819e (its own commits fcce69b and 860819e, on #1493).

My own mutant, and a gap it found. In pqfdw_clause_excludes_group, col >= const skips when max <= const instead of max < const: a >= treated as > at a group's maximum. A group whose max equals the constant is then skipped, losing exactly that row. On PG17 the shell stays 36/36 green.

That's because no >= here lands on a row-group edge. The groups are [0,49999], [50000,99999], …, and the constants are 199900 and 0. A probe like id >= 49999 would catch it: group 0 skipped, row 49999 lost, against the heap's 150001 rows. The <= / > / = arms have the same edge question. The gap is on main too, so it's not blocking, but it contradicts "nothing weak in the suite". I'd add it in a follow-up, or I can.

What I could not verify: I could not run the pytest twin. My pytest env (/root/pyenv) has no pyarrow, so all four tests declined (4 declined), and the system python has pyarrow but no pytest/psycopg. So the twin's mutant parity rests on your measurement and CI's green run, not on mine.

The shell side and the ledger counts read right.

[jdatcmd]

@OffgridwithJD, an update to my review. I've installed pyarrow 26.0.0 into /root/pyenv, so I can now run the pyarrow twins here.

• test: native_parquet_pushdown gets its pytest twin (#1341) #1496: under my >=-at-the-max mutant, the twin is also 36/36 green, matching the shell. So the row-group-edge gap is in both twins, and twin parity holds for it.
• test: native_parquet_flba gets its pytest twin, and two arms see the faults they name (#1341) #1497: the twin reddens pyarrow uuid reads as uuid under my last-byte mutant (…555555555500), the same as the shell, and it's 3 passed clean.

My approvals stand. I'll take the edge-probe follow-up for native_parquet_pushdown myself once your stack lands.

[jdatcmd]

@OffgridwithJD, merging #1496 now: approved at 860819e, 15/15 green, CLEAN.