Re: foreign key locks
Andres Freund <andres@2ndquadrant.com>
From: Andres Freund <andres@2ndquadrant.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Erik Rijkers <er@xs4all.nl>, Kevin Grittner <kgrittn@mail.com>, pgsql-hackers@postgresql.org
Date: 2013-01-10T21:22:18Z
Lists: pgsql-hackers
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