Tom Lane <t...@sss.pgh.pa.us> wrote: > "Kevin Grittner" <kevin.gritt...@wicourts.gov> writes: >> [ circular trigger relationships ] > >> I expect the DELETE from a to delete related b record(s) and then >> succeed. Instead the UPDATE in b_del_trig causes delete of a to >> silently fail. > > The update causes the already-selected target row version of the > DELETE to be obsoleted, so heap_delete finds it has nothing to do. > I'm disinclined to mess with that logic. It's pretty astonishing behavior for application programmers. It's not unusual for triggers on detail from one table to maintain a status, count, or sum in a higher level table. When a DELETE from the higher level table causes deletes at the lower level, the lower level trigger really doesn't have any way to know that. I think this should be considered a bug. At the point where heap_delete finds that the tuple has expired, I think it should follow the ctid chain as long as xmax is from the same top-level transaction, and then decide if it has something to do. Normally, that would be zero iterations, so I doubt the performance impact is huge. I'm willing to mess with that logic if there's a chance that it will be accepted. I may *need* to even if it won't, to allow our migration to native PostgreSQL triggers to succeed -- we've been trying to work around it for the last few days, but the places where it's popping up are becoming increasingly hard to accommodate that way. -Kevin
-- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
