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  (Merlin Moncure <mmoncure@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Merlin Moncure
Дата:
Сообщение: Re: Concurrent HOT Update interference
Следующее
От: carla celiberti
Дата:
Сообщение: Re: Taking the "varattno" in "args" (where part of a query)