Re: remove spurious CREATE INDEX CONCURRENTLY wait

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: remove spurious CREATE INDEX CONCURRENTLY wait
Дата
Msg-id 20201118190928.vnztes7c2sldu43a@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: remove spurious CREATE INDEX CONCURRENTLY wait  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы "as quickly as possible" (was: remove spurious CREATE INDEX CONCURRENTLY wait)
Re: remove spurious CREATE INDEX CONCURRENTLY wait
Re: remove spurious CREATE INDEX CONCURRENTLY wait
Список pgsql-hackers
Hi,

On 2020-11-17 12:55:01 -0300, Alvaro Herrera wrote:
> ... ah, but I realize now that this means that we can use shared lock
> here, not exclusive, which is already an enormous improvement.  That's
> because ->pgxactoff can only be changed with exclusive lock held; so as
> long as we hold shared, the array item cannot move.

Uh, wait a second. The acquisition of this lock hasn't been affected by
the snapshot scalability changes, and therefore are unrelated to
->pgxactoff changing or not.

In 13 this is:
        LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
        MyPgXact->vacuumFlags |= PROC_IN_VACUUM;
        if (params->is_wraparound)
            MyPgXact->vacuumFlags |= PROC_VACUUM_FOR_WRAPAROUND;
        LWLockRelease(ProcArrayLock);

Lowering this to a shared lock doesn't seem right, at least without a
detailed comment explaining why it's safe. Because GetSnapshotData() etc
look at all procs with just an LW_SHARED ProcArrayLock, changing
vacuumFlags without a lock means that two concurrent horizon
computations could come to a different result.

I'm not saying it's definitely wrong to relax things here, but I'm not
sure we've evaluated it sufficiently.

Greetings,

Andres Freund



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: cutting down the TODO list thread
Следующее
От: Vlad Bokov
Дата:
Сообщение: CREATE AGGREGATE array_cat