WaitForOlderSnapshots refactoring
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:t39234psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 28, 2026 at 05:25 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 t39234_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 t39234_1 && git checkout t39234_1Patchset v1 (message #1) is on t39234_1
The attached patch factors out the CREATE INDEX CONCURRENTLY code that
waits for transactions with older snapshots to finish into a new
function WaitForOlderSnapshots().
This refactoring was part of a previously posted REINDEX CONCURRENTLY
patch. But this code is now also appearing as a copy-and-paste in the
ATTACH/DETACH PARTITION CONCURRENTLY thread, so it might be worth making
it an official thing.
The question is where to put it. This patch just leaves it static in
indexcmds.c, which doesn't help other uses. A sensible place might be a
new src/backend/commands/common.c. Or we make it non-static in
indexcmds.c when the need arises.
Thoughts?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Hi,
On 2018-08-20 14:35:34 +0200, Peter Eisentraut wrote:
The attached patch factors out the CREATE INDEX CONCURRENTLY code that
waits for transactions with older snapshots to finish into a new
function WaitForOlderSnapshots().
This refactoring was part of a previously posted REINDEX CONCURRENTLY
patch. But this code is now also appearing as a copy-and-paste in the
ATTACH/DETACH PARTITION CONCURRENTLY thread, so it might be worth making
it an official thing.
I'm doubtful that ATTACH should use this, but I think the refactoring is
a good idea regardless.
The question is where to put it. This patch just leaves it static in
indexcmds.c, which doesn't help other uses. A sensible place might be a
new src/backend/commands/common.c. Or we make it non-static in
indexcmds.c when the need arises.
Why not move it to procarray.c? Most of the referenced functionality
resides there IIRC.
Greetings,
Andres Freund
On 20/08/2018 14:39, Andres Freund wrote:
The question is where to put it. This patch just leaves it static in
indexcmds.c, which doesn't help other uses. A sensible place might be a
new src/backend/commands/common.c. Or we make it non-static in
indexcmds.c when the need arises.Why not move it to procarray.c? Most of the referenced functionality
resides there IIRC.
I was thinking about that, too. I thought that that would create a
circular dependency between lock.c and procarray.c, but seeing that
that's already the case, I guess it's OK. (lock.c includes procarray.h,
but procarray.c uses stuff from lock.h, even though it doesn't include
it directly.) I'll rework the patch accordingly.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services