Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dqjJT-0005i1-VO for pgsql-bugs@arkaria.postgresql.org; Sat, 09 Sep 2017 17:13:00 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dqjJS-0002b3-GH for pgsql-bugs@arkaria.postgresql.org; Sat, 09 Sep 2017 17:12:58 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dqjJQ-0002ar-Ul for pgsql-bugs@postgresql.org; Sat, 09 Sep 2017 17:12:57 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dqjJO-0008QE-9j; Sat, 09 Sep 2017 17:12:55 +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 v89H8o2i003703; Sat, 9 Sep 2017 13:08:50 -0400 From: Tom Lane To: Michael Paquier cc: phb07@apra.asso.fr, 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> Comments: In-reply-to Michael Paquier message dated "Sat, 09 Sep 2017 20:27:05 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3701.1504976930.1@sss.pgh.pa.us> Date: Sat, 09 Sep 2017 13:08:50 -0400 Message-ID: <3702.1504976930@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 Michael Paquier writes: > Crash is confirmed here so I am adding an open item. I have not dug > into the issue seriously, but at short glance we have a code path > trying to access something that has already been free'd: I think this can be blamed on commit c46c0e52. What is happening is that the AFTER triggers are queuing more triggers, which have TransitionCaptureStates associated, but ExecEndModifyTable thinks it can DestroyTransitionCaptureState unconditionally. When the subsidiary triggers eventually get executed, their ats_transition_capture pointers are pointing at garbage. 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. The other question that seems pretty relevant is why the subsidiary triggers, which are the constraint triggers associated with the tables' foreign keys, are getting queued with TransitionCaptureState pointers in the first place. This seems horridly expensive and unnecessary. It also directly contradicts the claim in MakeTransitionCaptureState that constraint triggers cannot have transition tables. 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