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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers