Re: remove spurious CREATE INDEX CONCURRENTLY wait

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: remove spurious CREATE INDEX CONCURRENTLY wait
Дата
Msg-id 20201117000832.GA19824@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: remove spurious CREATE INDEX CONCURRENTLY wait  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: remove spurious CREATE INDEX CONCURRENTLY wait
Список 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 по дате отправления:

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: Terminate the idle sessions
Следующее
От: Greg Nancarrow
Дата:
Сообщение: Crash in virtual file descriptor FDDEBUG code