Doing that just moves the problem from the time of the UPDATE to the time of the COMMIT. It is still possible to get a deadlock and I'm not sure how making it deferrable helps in this case.
You can still end up with a deadlock like this: CON1: BEGIN; CON1: SELECT * FROM A WHERE id = 1 FOR UPDATE; CON2: BEGIN; CON2: UPDATE B SET blah1 = 42 WHERE id = 1; -- OK, UPDATE1 CON1: UPDATE B SET blah3 = 42 WHERE id = 1; -- blocks because of the transaction in CON2 CON2: UPDATE B SET blah2 = 42 WHERE id = 1; -- OK, UPDATE1 CON2: COMMIT; -- causes deadlock ERROR: deadlock detected On Tue, Jul 9, 2013 at 12:57 PM, bricklen <brick...@gmail.com> wrote: > > On Tue, Jul 9, 2013 at 9:02 AM, <pgn...@gmail.com> wrote: > >> The following bug has been logged on the website: >> >> Bug reference: 8290 >> Logged by: pgnoob >> Email address: pgn...@gmail.com >> PostgreSQL version: 8.4.13 >> Operating system: CentOS Linux >> Description: >> >> I experienced a db deadlock. After tracking down the problem I attributed >> it to some unusual locking behavior in postgresql where it acquires locks >> in >> an unexpected way that contributed to the deadlock. >> >> >> ALTER TABLE B ADD CONSTRAINT fkrefa FOREIGN KEY (a_id) REFERENCES A(id) >> MATCH FULL; >> > > Try those steps again with the FK "DEFERRABLE INITIALLY DEFERRED" > Eg. > ALTER TABLE B ADD CONSTRAINT fkrefa FOREIGN KEY (a_id) REFERENCES A(id) > MATCH FULL deferrable initially deferred; > >
