Thread: WaitForOlderSnapshots refactoring
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
Attachment
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