pgcolumnar.stats() returns zero rows on its first call in a pgc-harness cluster, correct on every later call

[jdatcmd]

Observed while building the #405 fold-deferral suite, PG17 non-assert, main + the deferral branch (the deferral code does not touch stats()).

Inside a pgc_setup cluster, the FIRST pgcolumnar.stats(rel) call of the suite returns zero rows; an immediately following identical call from a fresh backend returns the correct row-group count. Deterministic across three suite runs:

GROUPS="$(q "SELECT count(*) FROM pgcolumnar.stats('fd_t'::regclass)")"   -> 0
# next line, fresh psql:
SELECT count(*) FROM pgcolumnar.stats('fd_t'::regclass)                   -> 6

Fixture: CREATE TABLE ... USING pgcolumnar; set_options(stripe_row_limit => 20000); INSERT 120000 rows; CREATE TABLE heap AS SELECT * — each in its own psql session, all committed long before the stats call. EXPLAIN's Columnar Chunk Groups Total reads 6 at the same moment the first stats() call reads 0.

Not reproducible outside the harness: the same statement sequence against a hand-initdb'd cluster (both single-session and per-statement sessions, TCP, same binaries) returns 6 on the very first call. So the trigger involves something in the harness cluster configuration (pgc_setup's deterministic-GUC conf lines are the visible difference), which is exactly why this is filed rather than debugged past midnight: the repro is test/native_fold_deferral.sh's premise with the warm-read workaround reverted.

Until root-caused, the #405 suite reads stats() after the first EXPLAIN (warm) and cross-checks it against the EXPLAIN's own group total, so a recurrence fails loudly with both numbers in hand.

[jdatcmd]

Retracted: stats() was never broken. The bug was my suite variable's NAME.

The suite assigned its group count to a variable called GROUPS — which is bash's builtin array of the caller's group ids, and assignments to it are silently ignored. The suite therefore read root's primary gid (0) forever, while every debug probe I added (which only ever READ a fresh command substitution, never assigned) printed the correct 6. That asymmetry — probes always right, assignments always "wrong" — sent me through stream separation, byte dumps, and a single-line rewrite before the impossible pattern (a value no assignment could change) identified the builtin.

pgcolumnar.stats() returns correct results on every call, first or not, in and out of the harness. My apology to the function.

What this issue leaves behind is the lesson, recorded in the suite comment and my gotcha notes: never name a suite variable GROUPS, UID, EUID, BASH*, or any other bash special — the failure is silent, survives cat -A, and masquerades perfectly as the code under test lying.