"Roman Lytovchenko" <roman.lytovche...@gmail.com> writes: > Description: multiple update with on cascade
Yeah, this is a bug all right, see my analysis at http://archives.postgresql.org/pgsql-hackers/2011-10/msg01361.php As a stopgap workaround, you could manually rename the triggers generated by the FK constraint so that they execute in the opposite order. Try a command like this to see the triggers on t2: regression=# select tgname, tgfoid::regproc from pg_trigger where tgrelid = 't2'::regclass order by 1; tgname | tgfoid ----------------------------+----------------------- RI_ConstraintTrigger_53586 | "RI_FKey_check_ins" RI_ConstraintTrigger_53587 | "RI_FKey_check_upd" RI_ConstraintTrigger_53588 | "RI_FKey_cascade_del" RI_ConstraintTrigger_53589 | "RI_FKey_cascade_upd" (4 rows) (The numbers at the ends of the names will almost certainly be different for you.) You need to adjust the names so that the RI_FKey_check_upd trigger sorts after the one that calls RI_FKey_cascade_upd. For example, on my copy of your test case, update pg_trigger set tgname = 'RI_ConstraintTrigger_x53587' where tgname = 'RI_ConstraintTrigger_53587' and tgrelid = 't2'::regclass; followed by starting a fresh database session fixes it. (You'll need to be superuser to mess with the system catalogs directly like that.) Keep in mind that until we fix this in the source code, any freshly-created self-referential FK constraint is vulnerable to the same problem; in particular the problem would come back if you did a dump and reload. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs