Re: remove spurious CREATE INDEX CONCURRENTLY wait - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: remove spurious CREATE INDEX CONCURRENTLY wait
Date
Msg-id 20201117000832.GA19824@alvherre.pgsql
Whole thread Raw
In response to Re: remove spurious CREATE INDEX CONCURRENTLY wait  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: remove spurious CREATE INDEX CONCURRENTLY wait  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
On 2020-Nov-09, Tom Lane wrote:

> Michael Paquier <michael@paquier.xyz> writes:
> >> +        LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
> >> +        MyProc->vacuumFlags |= PROC_IN_SAFE_IC;
> >> +        ProcGlobal->vacuumFlags[MyProc->pgxactoff] = MyProc->vacuumFlags;
> >> +        LWLockRelease(ProcArrayLock);
> 
> > I can't help noticing that you are repeating the same code pattern
> > eight times.  I think that this should be in its own routine, and that
> > we had better document that this should be called just after starting
> > a transaction, with an assertion enforcing that.
> 
> Do we really need exclusive lock on the ProcArray to make this flag
> change?  That seems pretty bad from a concurrency standpoint.

BTW I now know that the reason for taking ProcArrayLock is not the
vacuumFlags itself, but rather MyProc->pgxactoff, which can move.

On the other hand, if we stopped mirroring the flags in ProcGlobal, it
would mean we would have to access all procs' PGPROC entries in
GetSnapshotData, which is undesirable for performance reason (per commit
5788e258bb26).



pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: Terminate the idle sessions
Next
From: Greg Nancarrow
Date:
Subject: Crash in virtual file descriptor FDDEBUG code