On Wed, Apr 27, 2011 at 7:15 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)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

In response to

• Re: SSI non-serializable UPDATE performance at 2011-04-27 18:15:02 from Kevin Grittner

Responses

• Re: SSI non-serializable UPDATE performance at 2011-04-28 07:55:19 from Dan Ports

pgsql-hackers by date

Next:	From: Simon Riggs	Date: 2011-04-28 07:53:37
	Subject: Re: SIREAD lock versus ACCESS EXCLUSIVE lock
Previous:	From: Simon Riggs	Date: 2011-04-28 07:40:10
	Subject: Re: SSI non-serializable UPDATE performance