Date: Wed, 31 Oct 2012 17:22:10 -0300
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Simon Riggs <simon@2ndQuadrant.com>
Cc: Noah Misch <noah@leadboat.com>, Kevin Grittner <kgrittn@mail.com>,
	Andres Freund <andres@2ndquadrant.com>, pgsql-hackers@postgresql.org
Subject: Re: foreign key locks
Message-ID: <20121031202209.GF23139@alvh.no-ip.org>
References: <20121029121833.306930@gmx.com>
	<20121031193536.GA1651@tornado.leadboat.com>
	<CA+U5nMKK8oOcoxTtMO9ZgT6YYGYH2RQoDt15RXXyMh+Sp0tNmA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: 
 <CA+U5nMKK8oOcoxTtMO9ZgT6YYGYH2RQoDt15RXXyMh+Sp0tNmA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Content-Transfer-Encoding: quoted-printable

Simon Riggs wrote:
> On 31 October 2012 19:35, Noah Misch <noah@leadboat.com> wrote:
> > On Mon, Oct 29, 2012 at 08:18:33AM -0400, Kevin Grittner wrote:
> >> Andres Freund wrote:

> >> > The point is the introduction of a weaker lock level which can be
> >> > used by the ri triggers. I don't see any imperative that the
> >> > semantics of the old lock level need to be redefined. That just
> >> > seems dangerous to me.
> >>
> >> I agree with Andres here -- the new lock level is needed within RI
> >> triggers, and we might as well expose it for application programmer
> >> use (with proper documentations), but there's no reason to break
> >> existing application code by making the semantics of SELECT FOR
> >> UPDATE less strict than they were before. Let's keep that term
> >> meaning exactly the same thing if we can, and use new names for the
> >> new levels.
> >
> > +1.  I had not considered this angle during previous reviews, but I a=
gree with
> > Andres's position.  Since this patch does not strengthen the stronges=
t tuple
> > lock relative to its PostgreSQL 9.2 counterpart, that lock type shoul=
d
> > continue to use the syntax "FOR UPDATE".  It will come to mean "the l=
ock type
> > sufficient for all possible UPDATEs of the row".

Yeah, I agree with this too.

> So we have syntax
>=20
> FOR NON KEY UPDATE
> FOR KEY UPDATE
>=20
> KEY is the default, so FOR UPDATE is a synonym of FOR KEY UPDATE

Not really sure about the proposed syntax, but yes clearly we need some
other syntax to mean "FOR NON KEY UPDATE".  I would rather keep FOR
UPDATE to mean what I currently call FOR KEY UPDATE.  More proposals for
the other (weaker) lock level welcome (but if you love FOR NON KEY
UPDATE, please chime in too)

--=20
=C1lvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services