On Wed, Apr 27, 2011 at 7:15 PM, Kevin Grittner <kevin.gritt...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
