Re: SSI non-serializable UPDATE performance - Mailing list pgsql-hackers

From Dan Ports
Subject Re: SSI non-serializable UPDATE performance
Date
Msg-id 20110428075519.GE1432@csail.mit.edu
Whole thread Raw
In response to Re: SSI non-serializable UPDATE performance  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: SSI non-serializable UPDATE performance  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: Simon Riggs
Date:
Subject: Re: SIREAD lock versus ACCESS EXCLUSIVE lock
Next
From: Valeriano Cossu
Date:
Subject: Re: [ANNOUNCE] PostgreSQL Core Team