Progress reporting: a debug trace and a test framework
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t254082psql -h localhost -U postgresBuilt from patchset v1 (message #1), October 23, 2026 at 01:05 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t254082_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t254082_1 && git checkout t254082_1Patchset v1 (message #1) is on t254082_1
The two patches attached add a debug trace and a test framework for
progress reporting. They were first posted in [1]/messages/by-id/179018818545.3031865.5809261654654798774@gmail.com; they get their own
thread now, as Michael suggested.
0001 adds PROGRESS_DEBUG. With it defined, every change to a backend's
progress state is logged at LOG_SERVER_ONLY, so a test can read back the
exact sequence of reports a command makes, without needing concurrency or
injection points. It is compiled out by default: with it undefined the
object code of backend_progress.c is unchanged (the same instruction
stream, only the line numbers baked into existing elog calls shift), and
the test below skips, so "make check" and "meson test" are not any slower.
0002 adds the test module test_progress. It replays each backend's trace
and checks the rules that hold for every command -- values continue from
the last one logged, counters do not decrease or only go back to 0, done
counters stay within their totals, phases take defined values, and a
command writes only its own parameters -- and then the exact succession of
phases for each command. It also checks every parameter of
commands/progress.h against a description, on any build, so a new or
renumbered parameter has to be described before the test passes.
These checks have already been useful: the trace is what found the three
blips fixed in 3be29d9346d, and the description check flagged, while
rebasing, that 1378aa13430 had added PROGRESS_VACUUM_CURRENT_INDEX_RELID
without describing it.
Run on master, the framework also flags two harmless blips that no view
exposes: when one command builds or vacuums several indexes in a row
(REPACK, VACUUM FULL, VACUUM in several cycles), the index-build tuple
counter and the dead-item counters step straight to the next round's
value instead of first going back to 0. The test sets these aside as
known-accepted (listed in @ACCEPTED, the dead-item one under a TODO) so
the suite is green; they are harmless and I have left the behavior as it
is. Resetting the counters in every build and cycle removes them and
makes the dead-item counters match their documented "collected since the
last cycle" meaning; I can post that as a small optional follow-up if it
is wanted.
[1]: /messages/by-id/179018818545.3031865.5809261654654798774@gmail.com