Cc: pgsql-hackers@postgresql.org,"Alvaro Herrera" <alvherre@2ndquadrant.com>
Content-Type: text/plain; charset="utf-8"
Date: Mon, 29 Oct 2012 08:18:33 -0400
From: "Kevin Grittner" <kgrittn@mail.com>
Message-ID: <20121029121833.306930@gmx.com>
MIME-Version: 1.0
Subject: Re: foreign key locks
To: "Andres Freund" <andres@2ndquadrant.com>,"Simon Riggs"
	<simon@2ndquadrant.com>
Content-Transfer-Encoding: 8bit

Andres Freund wrote:
> On Sunday, October 28, 2012 11:47:16 PM Simon Riggs wrote:
>> Andres Freund <andres@2ndquadrant.com> wrote:

>>> * Is it ok to make FOR UPDATE somewhat weaker than before? In 9.2
>>> and earlier you could be sure that if you FOR UPDATE'ed a row you
>>> could delete it. Unless I miss something now this will not block
>>> somebody else acquiring a FOR KEY SHARE lock, so this guarantee
>>> is gone.
>> 
>> Yes, that is exactly the point of this.
> 
> 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.

We already present a barrier to people migrating from Oracle because
SELECT FOR UPDATE in PostgreSQL is weaker than it is in Oracle (where
it is just as strong as if an actual UPDATE were done -- write
conflicts and all); let's not increase the barrier by making SELECT
FOR UPDATE even weaker.

-Kevin