Date: Tue, 17 Aug 2004 08:09:19 -0700 (PDT)
From: Stephan Szabo <sszabo@megazone.bigpanda.com>
To: Markus Bertheau <twanger@bluetwanger.de>
Cc: Bruno Wolff III <bruno@wolff.to>, pgsql-sql@postgresql.org
Subject: Re: SELECT MAX(c) FROM (SELECT ... FOR UPDATE) AS foo
In-Reply-To: <1092752492.2627.23.camel@dicaprio.akademie1.de>
Message-ID: <20040817075821.V61699@megazone.bigpanda.com>
References: <1092740863.2627.17.camel@dicaprio.akademie1.de>
	<20040817141229.GA15770@wolff.to>
	<1092752492.2627.23.camel@dicaprio.akademie1.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Tue, 17 Aug 2004, Markus Bertheau wrote:

> =D0=92 =D0=92=D1=82=D1=80, 17.08.2004, =D0=B2 16:12, Bruno Wolff III =D0=
=BF=D0=B8=D1=88=D0=B5=D1=82:
> > > SELECT MAX(position) FROM (SELECT position FROM classes WHERE name =
=3D
> > > 'foo' FOR UPDATE OF classes) AS foo
> > >
> > > It's clear which rows should be locked here, I think.
> >
> > Even if it was allowed, it probably wouldn't be good enough because it =
won't
> > protect against newly inserted records.
>
> Can you detail an example where this wouldn't be good enough?

Another transaction can come along and insert a row with name=3D'foo' into
classes with a higher position value after you've done the above but
before you commit.

T1: begin;
T2: begin;
T1: select max(position) from (select position from classes where
name=3D'foo' for update of classes) as foo;
 -- say this gets 5
T2: insert into classes (name, position) values ('foo', 10);
 -- This wouldn't be blocked by the for update lock.
T2: commit;
 -- now if you were to do the T1 select above, you'd get a different
 -- answer in read committed.

If we had predicate locking, I think you could probably manage these cases
in serializable mode, but for now I'm not sure anything less than a table
lock would do.