On Wed, Apr 27, 2011 at 7:15 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> (1) If a tuple which is predicate locked, or sits on a predicate-
> locked page, is updated, the predicate lock is duplicated for the
> new tuple. We have found patterns of updates involving four or more
> transactions where a non-serializable transaction can hide
> serialization anomalies among serializable transactions if we don't
> do this. Someone suggested that we could take out this call and
> just document that serializable transactions may not comply with the
> standard-defined behavior when there are concurrent non-serializable
> transactions. We were unable to show a measurable performance hit
> on this, although this was just with 32 clients hitting a 16
> processor machine. There was at least a theoretical possibility
> that with higher levels of concurrency there could have been a new
> contention point for a LW lock here which could affect performance.
> 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.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
