From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@enterprisedb.com>
cc: Michael Paquier <michael.paquier@gmail.com>,
        Andrew Gierth <rhodiumtoad@postgresql.org>,
        PostgreSQL mailing lists <pgsql-bugs@postgresql.org>,
        Kevin Grittner <kgrittn@gmail.com>
Subject: Re: BUG #14808: V10-beta4, backend abort
In-reply-to: 
 <CAEepm=0GJpW9hYTDHvPDRWxBGRQtEaKZ8PLo3eRDgYmuV8A3bg@mail.gmail.com>
References: <20170909064853.25630.12825@wrigleys.postgresql.org>
 <CAB7nPqRBE35VOtvU=VfV66sqvV5L+raGi8R64WBD3jjS3G4HZA@mail.gmail.com>
 <3702.1504976930@sss.pgh.pa.us> <9324.1504983594@sss.pgh.pa.us>
 <25326.1505070173@sss.pgh.pa.us>
 <CAEepm=0rNhRe8Zjf46H__au+KrAYktbefpNyFHVqn9ZfFyKV_Q@mail.gmail.com>
 <14016.1505135324@sss.pgh.pa.us> <8201.1505149431@sss.pgh.pa.us>
 <CAEepm=2P2a4hO8dED+1g0emRUbWFmc85Ahug4YbbrO0GYwYkiA@mail.gmail.com>
 <13342.1505177580@sss.pgh.pa.us>
 <CAEepm=015ZFuo2AEFF+maS2AvL7PGkdZ_=uUErpPXzNm3TbGWQ@mail.gmail.com>
 <CAEepm=0d24nWCN14MdkS4Xp3aynN-2M8z7bszyWJ=MmCHAJ_Ww@mail.gmail.com>
 <CAEepm=2st+4LzooeaALSWJUAX_xe8Vve9VDr1BQkdJFiOhS-Kw@mail.gmail.com>
 <630.1505425555@sss.pgh.pa.us>
 <CAEepm=2Fu=W7MFqsTcBGQEFwv05F6DWV0mv+vnPXReUcmeZ4Kg@mail.gmail.com>
 <25637.1505489314@sss.pgh.pa.us> <32587.1505503595@sss.pgh.pa.us>
 <CAEepm=0GJpW9hYTDHvPDRWxBGRQtEaKZ8PLo3eRDgYmuV8A3bg@mail.gmail.com>
Comments: In-reply-to Thomas Munro <thomas.munro@enterprisedb.com>
	message dated "Sat, 16 Sep 2017 13:45:27 +1200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <21763.1505533100.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 15 Sep 2017 23:38:20 -0400
Message-ID: <21764.1505533100@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-bugs-owner@postgresql.org

Thomas Munro <thomas.munro@enterprisedb.com> writes:
> On Sat, Sep 16, 2017 at 7:26 AM, Tom Lane <tgl@sss.pgh.pa.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


--=20
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs