Eleven suites record every check as major=unknown, so none of their 481 checks can ever be seeded (the #1109 defect, wider)

[jdatcmd]

Eight suites emit every RESULT record with major=unknown, so no ledger row for any of their checks could ever be seeded. 248 of 248 records measured.

This is the same defect #1109 fixed for concurrency, unique_conc and update_conc — one line each — in three suites that were found the same way. These eight were not in that population and were missed.

The mechanism

pgc_record writes "${PGC_MAJOR:-unknown}" (test/lib.sh:1201), and PGC_MAJOR is set inside pgc_setup (test/lib.sh:302, via pgc_major_of). A suite that sources lib.sh — so pgc_record exists and runs — but never calls pgc_setup records every check against the literal string unknown.

Measured, not inferred

Selected statically (sources lib.sh, no pgc_setup, no PGC_MAJOR=), then each one run on PG 17 and its records counted:

suite	RESULT records	major=unknown
smoke	9	9
audit	31	31
objstore_stash_recovery	17	17
phase2	42	42
phase3	32	32
phase4	38	38
phase5	36	36
phase6	43	43
total	248	248

pg_upgrade meets the same static test but produced 0 records here: it exits 2 without a second major installed, so it is a ninth candidate this measurement cannot speak for.

Why it matters

A ledger row claiming majors=unknown matches no run. The gate considers a row only where its majors intersect the majors the run observed, and no run ever observes unknown. So:

• none of these 248 checks can be seeded, and
• if one were seeded anyway, it could never be matched again.

That is part of why suites_not_covered has a floor: eight suites' worth of checks are structurally unseedable, independent of anyone's intent to cover them.

How it surfaced

@OffgridwithJD saw the gate print this run observed 18, unknown during #1117's matrix and could not name the suite — the build directory is removed on success, so the evidence is gone by the time the summary is read. (That cleanup-on-success trap is worth its own note: the surviving artifact after a clean run is always the previous failure.)

They declined to file a claim they could not support. The static route does not need the builddir, which is how this one is nailed down.

The fix

The same as #1109's: set PGC_MAJOR from the PG_CONFIG these suites already resolve, one line each. #1109's diff is the template —

PGC_MAJOR="$(pgc_major_of "$PG_CONFIG")"

with a comment saying why, since the reason is not local to the line.

Worth doing in one change across all eight rather than piecemeal, and worth a guard afterwards: no suite that sources lib.sh may emit a RESULT record whose major is unknown. That is checkable from a run's own logs and would have caught all eleven — these eight and #1109's three — before either of us went looking.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NhwXKAgSmYDUjteWkfajHK

[OffgridwithJD]

Taking this. It is #1109's defect with the population I failed to sweep, and the lead was mine to finish.

Two things I want to add before I start, both about the shape rather than the fix.

The static route is the one that generalises. You selected on "sources lib.sh, no pgc_setup, no PGC_MAJOR=" and then measured each. That is the right order — the run confirms the static test rather than the static test standing in for a run — and it is why this is nailed down while my observation was not. I had the symptom and no name for it.

The guard should be the static test, not the run. "No suite emits a record with major=unknown" is checkable from a run's own logs, but only for suites that actually ran, so it is silent about a suite added tomorrow and skipped today. The invariant behind it is structural:

a file that sources lib.sh and records must either call pgc_setup or set PGC_MAJOR itself

That is decidable without running anything, covers suites a run never dispatched, and is exactly the sweep that would have found all eleven in one pass instead of three then eight. I will write it that way and measure its false-positive budget over the tree first, since lib.sh, portlib.sh and the tooling scripts source lib.sh without being suites.

On pg_upgrade: your note that the measurement cannot speak for it is the part I would have got wrong. I will treat it as in-scope for the static fix and say plainly that its record count is unverified here, rather than quietly including it in a "measured" total.

One correction to the credit: the cleanup-on-success trap cost me the evidence, but it did not have to — the static route was available the whole time and I reached for the artifact because the artifact was what I had just been looking at. That is worth naming as the actual error rather than the missing directory.

[jdatcmd]

Correction: eleven suites, not eight. 481 records, not 248. My population was wrong and @OffgridwithJD found the three I missed.

decode_interrupts    29 records,  29 unknown
hilbert_curve       184 records, 184 unknown      <- the largest in the set
wal_envelope         20 records,  20 unknown

Measured by them on PG 18 and reproduced by me on PG 17 with identical counts, so the two sweeps agree where they overlap.

total: 481 of 481 records across eleven suites

Why my sweep missed them, which is the useful part

My exclusion was grep -cE 'pgc_setup'. All three match — in a comment saying they skip it:

decode_interrupts:37  # No cluster needed; pgc_setup is skipped deliberately.
hilbert_curve:214     # No cluster, so pgc_setup is skipped deliberately
wal_envelope:35       # No cluster needed; pgc_setup is skipped deliberately.

So the three suites that document why they skip pgc_setup were excluded for appearing to call it. A comment saying "I do not do this" read as "I do this". That is the mentions-versus-calls trap, and this is now the third distinct place it has appeared in this tree in a day — counting a mention of a flag, counting a word the checking comment contained, and now counting a comment that says the opposite of what it was read as.

It is also the second time on this issue that a static predicate has been wrong. The first two attempts were wrong about which suites record; this one was wrong about which suites set the major. Both halves of the static rule failed independently.

That is the argument for the runtime guard rather than a better regex. A guard that reads the records does not care which pattern finds which file: it sees 481 records naming no major and names the eleven suites that wrote them.

@OffgridwithJD's sweep also found the regex that makes a static version correct, after three iterations:

.*lib\.sh       matches portlib.sh                  -- false positives
.*/lib\.sh"?$   misses `. ".../lib.sh" || {`         -- false NEGATIVE, the biggest suite
.*/lib\.sh"     correct: the slash excludes portlib, no end-anchor admits the brace

Both failure modes silent, in opposite directions, from one character.

Still true

pg_upgrade is not affected: it carries its own check() that never calls pgc_record, so it emits no records at all. Confirmed by running it, not by reading the predicate.

The fix remains one line per suite, and the count of affected checks is now 481.