pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Michael Paquier <michael.paquier@gmail.com>
Cc: Andrew Gierth <rhodiumtoad@postgresql.org>
Cc: PostgreSQL mailing lists <pgsql-bugs@postgresql.org>
Cc: Kevin Grittner <kgrittn@gmail.com>
Subject: Re: BUG #14808: V10-beta4, backend abort
Date: Fri, 15 Sep 2017 23:38:20 -0400
Message-ID: <21764.1505533100@sss.pgh.pa.us> (raw)
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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-bugs>

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


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



view thread (28+ messages)

Message-ID: <21764.1505533100@sss.pgh.pa.us>
Permalink:  ../21764.1505533100@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/21764.1505533100@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: tgl@sss.pgh.pa.us, thomas.munro@enterprisedb.com, michael.paquier@gmail.com, rhodiumtoad@postgresql.org, kgrittn@gmail.com
  Subject: Re: BUG #14808: V10-beta4, backend abort
  In-Reply-To: <21764.1505533100@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox