Re: Concurrent HOT Update interference
От | Merlin Moncure |
---|---|
Тема | Re: Concurrent HOT Update interference |
Дата | |
Msg-id | CAHyXU0x8-Wm-rQN_6biYR-85HPJzSw_JHrxR0iDdju++a9-ttQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Concurrent HOT Update interference (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Concurrent HOT Update interference
|
Список | pgsql-hackers |
On Fri, May 10, 2013 at 5:23 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > Currently, when we access a buffer for a HOT update we check to see if > its possible to get a cleanup lock so we can clean the buffer. > > Currently, UPDATEs and DELETEs pin buffers during the scan phase and > then re-lock the buffer to update. > > So what we have is that multiple UPDATEs repeatedly accessing the same > block will prevent each other from successful cleanup, since while one > session is performing the update, the second session is pinning the > block with an indexscan. wait -- you can't acquire a cleanup lock if the buffer is pinned by at least one other session? yeah -- that would defeat HOT for many important cases. this should be pretty easy to demonstrate in simulated testing. merlin
В списке pgsql-hackers по дате отправления: