Date: Fri, 11 Jan 2013 13:10:49 -0300
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Andres Freund <andres@2ndquadrant.com>
Cc: Erik Rijkers <er@xs4all.nl>, Kevin Grittner <kgrittn@mail.com>,
	pgsql-hackers@postgresql.org
Subject: Re: foreign key locks
Message-ID: <20130111161049.GD4208@alvh.no-ip.org>
References: <20121129152326.69330@gmx.com>
	<20121129160220.GA4942@alvh.no-ip.org>
	<20121129161654.GB4942@alvh.no-ip.org>
	<b1a78c715f9195e6f96546c8e723afd8.squirrel@webmail.xs4all.nl>
	<20121228204847.GD4150@alvh.no-ip.org>
	<20130110210040.GB4110@alvh.no-ip.org>
	<20130110212218.GE4329@awork2.anarazel.de>
	<20130111151147.GB4208@alvh.no-ip.org>
	<20130111151930.GB6049@awork2.anarazel.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <20130111151930.GB6049@awork2.anarazel.de>
User-Agent: Mutt/1.5.21 (2010-09-15)
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Andres Freund wrote:

> No, I was thinking about an update without triggers present.
>=20
> T0: CREATE TABLE tbl(id serial pk, name text unique, data text);
> T1: BEGIN; -- read committed
> T1: UPDATE tbl SET name =3D 'foo' WHERE name =3D 'blarg'; /* key update o=
f row id =3D 1 */
> T2: BEGIN; -- read committed
> T2: UPDATE tbl SET name =3D 'blarg', data =3D 'blarg' WHERE id =3D 1; /* =
no key update, waiting */
> T1: COMMIT;
> T2: /* UPDATE follows to updated row, due to the changed name its a key u=
pdate now */
>=20
> Does that make sense?

So I guess your question is "is T2 now holding a TupleLockExclusive
lock?"  To answer it, I turned your example into a isolationtester spec:

setup
{
CREATE TABLE tbl(id serial primary key, name text unique, data text);
INSERT INTO tbl VALUES (1, 'blarg', 'no data');
}

teardown
{
DROP TABLE tbl;
}

session "s1"
step "s1b" { BEGIN; }
step "s1u" { UPDATE tbl SET name =3D 'foo' WHERE name =3D 'blarg'; }
step "s1c" { COMMIT; }

session "s2"
step "s2b" { BEGIN; }
step "s2u" { UPDATE tbl SET name =3D 'blarg', data =3D 'blarg' WHERE id =3D=
 1; }
step "s2c" { COMMIT; }

session "s3"
step "s3l" { SELECT * FROM tbl FOR KEY SHARE; }

permutation "s1b" "s1u" "s2b" "s2u" "s1c" "s3l" "s2c"


And the results:
Parsed test spec with 3 sessions

starting permutation: s1b s1u s2b s2u s1c s3l s2c
step s1b: BEGIN;
step s1u: UPDATE tbl SET name =3D 'foo' WHERE name =3D 'blarg';
step s2b: BEGIN;
step s2u: UPDATE tbl SET name =3D 'blarg', data =3D 'blarg' WHERE id =3D 1;=
 <waiting ...>
step s1c: COMMIT;
step s2u: <... completed>
step s3l: SELECT * FROM tbl FOR KEY SHARE; <waiting ...>
step s2c: COMMIT;
step s3l: <... completed>
id             name           data=20=20=20=20=20=20=20=20=20=20=20

1              blarg          blarg=20=20=20=20=20=20=20=20=20=20


So session 3 is correctly waiting for session 2 to finish before being
ablt to grab its FOR KEY SHARE lock, indicating that session 2 is
holding a FOR UPDATE lock.  Good.

If I change session 1 to update the data column instead of name, session
3 no longer needs to wait for session 2, meaning session 2 now only
grabs a FOR NO KEY UPDATE lock.  Also good.

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


--=20
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers