Обсуждение: 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

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