feat(activity): xmin horizon and parallel worker grouping

[lesovsky]

Closes #148.

What

Three columns on the activity screen behind a PG 13+ query branch:

Column	Source	Answers
leader	coalesce(leader_pid, pid)	which parallel group this backend belongs to
backend_xid	backend_xid::text	has this transaction written anything
horizon_xacts	age(backend_xmin)	how far back it holds the xmin horizon

Together they answer, without leaving pgcenter for psql, the question the screen could not
answer before: which session is holding the xmin horizon and stopping vacuum, how long has it
been there, and is killing it cheap?

The branch is an early return above the existing selector switch, so PgStatActivityDefault
keeps naming that switch's default: case and PG 10–12 is untouched.

Two decisions worth reading

leader is derived, not the raw leader_pid. The original scope said to expose leader_pid
so workers sort next to their leader. That does not work: leader_pid is NULL for the leader
itself. Verified on a live 4-worker scan — the leader would have sorted into the NULL block
together with unrelated backends, away from its own workers. The derived column gives the leader
and all its workers one value.

backend_xid stays as a raw column even though only its presence matters. For an
idle-in-transaction session the query column shows the last statement, so a transaction that
ran INSERT then SELECT looks read-only. Reproduced: a session showed pg_sleep in query
while backend_xid = 784. That is the kill-safety question, and nothing else on the screen
answers it.

Two fixes that ride along

Neither is opportunistic — the feature makes both reachable.

Sorting of sparse columns (internal/stat/postgres.go). The comparator was chosen from a
single cell and blanks parsed as 0, so a blank was indistinguishable from a genuine zero and led
an ascending sort. That breaks this feature's primary story — ranking sessions by horizon — on a
column that is blank for most rows. The comparator is now chosen from the first non-empty cell and
blanks order last in both directions and all three modes. This is shared machinery: replslots
sorted by its default key is the most visible beneficiary, and its SQL already declared
DESC NULLS LAST, so the change brings Go into agreement with the query.

Tech debt [021] (report/report.go) — and it was three stale states, not one: the alignment
flag, the header-repeat counter, and the resolved sort-column index. The last one matters most
here because this feature inserts columns mid-layout, so a latched index silently sorts a report
by a different column. The zero-width guard in the truncation path is restored to match its twin
in top.

Review found two regressions, both fixed

Two reviewers independently reproduced them against develop:

• restoring the seed sort key put an out-of-range index into sort() — now bounds-checked inside
  sort itself, which also closes the pre-existing routes and the top caller (debt [025]);
• the zero-width guard converted a panic into a hang — pgcenter report in a pipe became an
  immortal process. doReport now drains on every error path (debt [026]).

A third finding was sharper: the feature's headline invariant had no automated cover. Mutants
replacing coalesce(leader_pid, pid) with a raw leader_pid, or wrapping backend_xid in a
coalesce(..., '0'), passed the entire suite. Both are now killed by value-level assertions in the
live query test.

Verification

• make test 70.3%, make lint 0 issues, gosec clean
• Live column names and order asserted against PG 14–19 — 6/6 pass, replacing a test that only
  checked the query did not error
• Existing report goldens pass unchanged — but they are a regression check, not coverage of the
  sort change: every activity golden sorts by pid, which is never blank
• Manual acceptance on live clusters, recorded in the feature's QA report

Stated limits: the PG 12→13 branch boundary cannot be verified live (the test image has PG
14–19 only) and rests on a table test pinning it from both sides; the load measurement reached 96
sessions, not the few hundred intended, because the fixture caps max_connections at 100.

Cost to be aware of

query moves 38 characters right for everyone, including users who never look at the horizon. On
a narrow terminal nothing changes qualitatively — query was already past the edge, which is what
horizontal scroll exists for. On a wide terminal it may now need one scroll step. Accepted
deliberately.

🤖 Generated with Claude Code