On 2013-01-11 13:10:49 -0300, Alvaro Herrera wrote: > Andres Freund wrote: > > > No, I was thinking about an update without triggers present. > > > > T0: CREATE TABLE tbl(id serial pk, name text unique, data text); > > T1: BEGIN; -- read committed > > T1: UPDATE tbl SET name = 'foo' WHERE name = 'blarg'; /* key update of row > > id = 1 */ > > T2: BEGIN; -- read committed > > T2: UPDATE tbl SET name = 'blarg', data = 'blarg' WHERE id = 1; /* no key > > update, waiting */ > > T1: COMMIT; > > T2: /* UPDATE follows to updated row, due to the changed name its a key > > update now */ > > > > 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:
Great! I reread the code and it does make sense the way its implemented now. I misremembered something... I vote for adding that spectest including some appropriate permutations. FWIW: Looks good to me. It could use another pair of eyes, but I guess that will have to come by being used. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
