On 2013-01-11 12:11:47 -0300, Alvaro Herrera wrote: > Andres Freund wrote: > > On 2013-01-10 18:00:40 -0300, Alvaro Herrera wrote: > > > Here's version 28 of this patch. The only substantive change here from > > > v26 is that I've made GetTupleForTrigger() use either LockTupleExclusive > > > or LockTupleNoKeyExclusive, depending on whether the key columns are > > > being modified by the update. This needs to go through EvalPlanQual, so > > > that function is now getting the lock mode as a parameter instead of > > > hardcoded LockTupleExclusive. (All other users of GetTupleForTrigger > > > still use LockTupleExclusive, so there's no change for anybody other > > > than FOR EACH ROW BEFORE UPDATE triggers). > > > > Is that enough in case of a originally non-key update in read committed > > mode that turns into a key update due to a concurrent key update? > > Hm, let me try to work through your example. You say that a transaction > T1 does a non-key update, and is working through the BEFORE UPDATE > trigger; then transaction T2 does a key update and changes the key > underneath T1? So at that point T1 becomes a key update, because it's > now using the original key values which are no longer the key? > > I don't think this can really happen, because T2 (which is requesting > TupleLockExclusive) would block on the lock that the trigger is grabbing > (TupleLockNoKeyExclusive) on the tuple. So T2 would sleep until T1 is > committed.
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? 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
