Re: remove spurious CREATE INDEX CONCURRENTLY wait
От | Simon Riggs |
---|---|
Тема | Re: remove spurious CREATE INDEX CONCURRENTLY wait |
Дата | |
Msg-id | CANP8+jJkh2CyfMC=k6x-zVQH0s6xtYsXqMezox0h7KrWQPjvnQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: remove spurious CREATE INDEX CONCURRENTLY wait (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Tue, 10 Nov 2020 at 03:02, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > > Yeah ... it would be much better if we can make it use atomics instead. > > I was thinking more like "do we need any locking at all". > > Assuming that a proc's vacuumFlags can be set by only the process itself, > there's no write conflicts to worry about. On the read side, there's a > hazard that onlookers will not see the PROC_IN_SAFE_IC flag set; but > that's not any different from what the outcome would be if they looked > just before this stanza executes. And even if they don't see it, at worst > we lose the optimization being proposed. > > There is a question of whether it's important that both copies of the flag > appear to update atomically ... but that just begs the question "why in > heaven's name are there two copies?" Agreed to all of the above, but I think the issue is miniscule because ProcArrayLock is acquired in LW_EXCLUSIVE mode at transaction commit. So it doesn't seem like there is much need to optimize this particular aspect of the patch. -- Simon Riggs http://www.EnterpriseDB.com/
В списке pgsql-hackers по дате отправления: