On Fri, May 10, 2013 at 8:33 AM, Andres Freund <[email protected]> wrote: > On 2013-05-10 08:28:24 -0500, Merlin Moncure wrote: >> On Fri, May 10, 2013 at 5:23 AM, Simon Riggs <[email protected]> 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 ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
