Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drUO0-0006bQ-3p for pgsql-bugs@arkaria.postgresql.org; Mon, 11 Sep 2017 19:28:48 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1drUNz-0001iI-IC for pgsql-bugs@arkaria.postgresql.org; Mon, 11 Sep 2017 19:28:47 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1drUNz-0001i9-7t for pgsql-bugs@postgresql.org; Mon, 11 Sep 2017 19:28:47 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1drUNw-0001a6-3e; Mon, 11 Sep 2017 19:28:46 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id v8BJOeil013985; Mon, 11 Sep 2017 15:24:40 -0400 From: Tom Lane To: Robert Haas cc: Michael Paquier , phb07 , Thomas Munro , Andrew Gierth , PostgreSQL mailing lists Subject: Re: BUG #14808: V10-beta4, backend abort In-reply-to: References: <20170909064853.25630.12825@wrigleys.postgresql.org> <3702.1504976930@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Mon, 11 Sep 2017 15:17:44 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13983.1505157880.1@sss.pgh.pa.us> Date: Mon, 11 Sep 2017 15:24:40 -0400 Message-ID: <13984.1505157880@sss.pgh.pa.us> List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-bugs Precedence: bulk Sender: pgsql-bugs-owner@postgresql.org Robert Haas writes: > On Sat, Sep 9, 2017 at 1:08 PM, Tom Lane wrote: >> My first instinct is to get rid of DestroyTransitionCaptureState >> altogether, on the grounds that the TransitionCaptureState will >> go away at transaction cleanup and we can't really get rid of it >> any sooner than that. > End of transaction, or end of query? I'm not sure what happens when > triggers are deferred, but I think there are a lot of cases when we > want to throw away the tuplestore immediately, not hold on to it for > the rest of the transaction. As things stand, it's end of subtransaction, because the TCSes are allocated in CurTransactionContext. See the argument in MakeTransitionCaptureState. And yes, this is inefficient. The quick-hack patch I committed yesterday only pays the price if you have RI triggers cascading changes into a table that also has triggers-with-transition-tables, but I can certainly believe that it could get expensive in such a case. The fix proposal discussed downthread should fix the inefficiency as well as the spec compliance problem. But personally I'm far more worried about the latter. 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