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? 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
