Re: {CREATE INDEX, REINDEX} CONCURRENTLY improvements - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: {CREATE INDEX, REINDEX} CONCURRENTLY improvements
Date
Msg-id 20201204143720.GA32678@alvherre.pgsql
Whole thread Raw
In response to Re: {CREATE INDEX, REINDEX} CONCURRENTLY improvements  (Dmitry Dolgov <9erthalion6@gmail.com>)
Responses Re: {CREATE INDEX, REINDEX} CONCURRENTLY improvements
List pgsql-hackers
On 2020-Dec-04, Dmitry Dolgov wrote:

> * This one is mostly for me to understand. There are couple of places
>   with a commentary that 'PROC_IN_SAFE_IC is not necessary, because the
>   transaction only takes a snapshot to do some catalog manipulation'.
>   But for some of them I don't immediately see in the relevant code
>   anything related to snapshots. E.g. one in DefineIndex is followed by
>   WaitForOlderSnapshots (which seems to only do waiting, not taking a
>   snapshot), index_set_state_flags and CacheInvalidateRelcacheByRelid.
>   Is taking a snapshot hidden somewhere there inside?

Well, they're actually going to acquire an Xid, not a snapshot, so the
comment is slightly incorrect; I'll fix it, thanks for pointing that
out.  The point stands: because those transactions are of very short
duration (at least of very short duration after the point where the XID
is obtained), it's not necessary to set the PROC_IN_SAFE_IC flag, since
it won't cause any disruption to other processes.

It is possible that I copied the wrong comment in DefineIndex.  (I only
noticed that one after I had mulled over the ones in
ReindexRelationConcurrently, each of which is skipping setting the flag
for slightly different reasons.)



pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: Single transaction in the tablesync worker?
Next
From: David Rowley
Date:
Subject: Re: Hybrid Hash/Nested Loop joins and caching results from subplans