Re: Concurrent HOT Update interference
От | Andres Freund |
---|---|
Тема | Re: Concurrent HOT Update interference |
Дата | |
Msg-id | 20130510133315.GA12806@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: Concurrent HOT Update interference (Merlin Moncure <mmoncure@gmail.com>) |
Ответы |
Re: Concurrent HOT Update interference
|
Список | pgsql-hackers |
On 2013-05-10 08:28:24 -0500, Merlin Moncure wrote: > 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? Correct. When you have a pin you are allowed to point into the buffer and a cleanup lock allows you to rearange the contents of a page. So that doesn't work well together. > yeah -- that would defeat HOT for many > important cases. this should be pretty easy to demonstrate in > simulated testing. Well, HOT itself works without getting a cleanup lock. Its just HOT pruning that doesn't. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: