From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: phb07@apra.asso.fr, Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Andrew Gierth <rhodiumtoad@postgresql.org>
Cc: PostgreSQL mailing lists <pgsql-bugs@postgresql.org>
Subject: Re: BUG #14808: V10-beta4, backend abort
Date: Sat, 09 Sep 2017 13:08:50 -0400
Message-ID: <3702.1504976930@sss.pgh.pa.us> (raw)
In-Reply-To: <CAB7nPqRBE35VOtvU=VfV66sqvV5L+raGi8R64WBD3jjS3G4HZA@mail.gmail.com>
References: <20170909064853.25630.12825@wrigleys.postgresql.org>
<CAB7nPqRBE35VOtvU=VfV66sqvV5L+raGi8R64WBD3jjS3G4HZA@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-bugs>
Michael Paquier <michael.paquier@gmail.com> 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
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, michael.paquier@gmail.com, thomas.munro@enterprisedb.com, rhodiumtoad@postgresql.org
Subject: Re: BUG #14808: V10-beta4, backend abort
In-Reply-To: <3702.1504976930@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