Re: Concurrent HOT Update interference

On Fri, May 10, 2013 at 8:33 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> On 2013-05-10 08:28:24 -0500, Merlin Moncure wrote:
>> On Fri, May 10, 2013 at 5:23 AM, Simon Riggs <simon(at)2ndquadrant(dot)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.

right. hm, I guess this is something to keep in mind if you start
going down the path of 'keep frequently accessed buffers pinned for
longer durations -- possibly even forever'.

merlin

--
Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers