Re: SSI non-serializable UPDATE performance

Поиск
Список
Период
Сортировка
От Dan Ports
Тема Re: SSI non-serializable UPDATE performance
Дата
Msg-id 20110428075519.GE1432@csail.mit.edu
обсуждение исходный текст
Ответ на Re: SSI non-serializable UPDATE performance  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: SSI non-serializable UPDATE performance  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Thu, Apr 28, 2011 at 08:43:30AM +0100, Simon Riggs wrote:
> > We added a quick return which didn't need to check any locks at the
> > front of this routine which is taken if there are no active
> > serializable transactions on the cluster at the moment of update.
> 
> Surprised to hear nobody mentioning memory reordering issues about
> that, but I'm not running Itaniums anywhere.

I did spend a while thinking about it. There aren't any memory
reordering issues with that optimization (even on the Alpha, where just
about anything goes).

The memory barrier when acquiring the buffer page lwlock acts as the
synchronization point we need. When we see that no serializable
transactions are running, that could have been reordered, but that read
still had to come after the lock was taken. That's all we need: even if
another backend starts a serializable transaction after that, we know
it can't take any SIREAD locks on the same target while we're holding
the buffer page lock.

Dan

-- 
Dan R. K. Ports              MIT CSAIL                http://drkp.net/


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: SIREAD lock versus ACCESS EXCLUSIVE lock
Следующее
От: Valeriano Cossu
Дата:
Сообщение: Re: [ANNOUNCE] PostgreSQL Core Team