Re: BUG #14808: V10-beta4, backend abort

Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> writes:
> On Sat, Sep 16, 2017 at 7:26 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Attached is an updated patch that incorporates the ideas you suggested.

> I was imagining that you would just need to keep a back pointer to the
> last queued event for the same (relation, command), since that's the
> only one you'd ever need to consider cancelling, and then no scanning
> would be needed. I am probably missing something.

There could be more than one after-statement trigger, no?

>> This is pretty messy but I think it's the best we can do as long as
>> RI actions are intermixed with other AFTER ROW triggers.

> It does seem like an inconsistency that it would be good to fix, but I
> don't immediately see how to make that happen with the current design.
> It would be interesting to know what DB2 does here in terms of trigger
> execution contexts and transition tables when you have a chain of 2, 3
> and 4 foreign key referential actions.

> Is it worth adding a test with an extra level of chaining in the self_ref case?

Would it show anything not shown by the three-level case?

> Is it worth adding tests for SET NULL and SET DEFAULT, to exercise the
> complete set of referential actions?

I think they're all about the same as far as this is concerned.

regards, tom lane