Count the last block of the validation scan in CIC progress
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:t254399psql -h localhost -U postgresBuilt from patchset v1 (message #1), October 26, 2026 at 05:34 PM.
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 t254399_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 t254399_1 && git checkout t254399_1Patchset v1 (message #1) is on t254399_1
Hi,
While CREATE INDEX CONCURRENTLY waits in "waiting for old snapshots",
pg_stat_progress_create_index shows blocks_done one short of
blocks_total for the whole wait: 442 of 443 on a 443-block table, with
a REPEATABLE READ transaction opened before the command and left open.
REINDEX CONCURRENTLY shows the same 442 of 443 in "waiting for old
snapshots" and in both "waiting for readers" phases.
heapam_index_validate_scan() reports each block when the scan starts
on it and nothing when the scan ends, so the last block is never
counted, and the phases that follow do not touch the block counters.
The attached patch reports rs_nblocks once the scan ends, the same as
the build scan's final report in heapam_index_build_range_scan(). The
validation scan does not use syncscan, so that is the total it
reported at its start. With it, the four waits show 443 of 443.
repro-f3.sh.txt reproduces it (bash repro-f3.sh.txt <bindir>); its
output on master and with the patch is attached. With the patch,
make check, the isolation suite, the injection_points tests,
test_misc's 010 and reindexdb's 090 pass (cassert build, no warnings).
I think this is for master only, like 3be29d9346d. It came up while
sweeping progress reporting for the framework in CF 7331. Mihail's
CIC series (v40-0004) moves this scan to tuples_done, so the fix is
for the code as it is today.
Regards,
Manu
On Mon, Oct 26, 2026 at 02:21:00PM -0300, Manu wrote:
heapam_index_validate_scan() reports each block when the scan starts
on it and nothing when the scan ends, so the last block is never
counted, and the phases that follow do not touch the block counters.
Hmm, yeah, it looks like you are right here. We aggregate a block
when we start scanning it, meaning that we're missing one block at the
end.
Adding one progress call at the end of the callback routine sounds
like the correct thing to do. I doubt that this is worth bothering
outside of HEAD, it's just a slight correctness issue, annoying but
not critical even if the waits can be long depending on the
transaction activity.
--
Michael