From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Concurrent HOT Update interference |
Date: | 2013-05-10 13:28:24 |
Message-ID: | CAHyXU0x8-Wm-rQN_6biYR-85HPJzSw_JHrxR0iDdju++a9-ttQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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? yeah -- that would defeat HOT for many
important cases. this should be pretty easy to demonstrate in
simulated testing.
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-05-10 13:30:58 | Re: In progress INSERT wrecks plans on table |
Previous Message | Tom Lane | 2013-05-10 13:13:56 | Re: Concurrent HOT Update interference |