From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: r.zharkov@postgrespro.ru
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15727: PANIC: cannot abort transaction 295144144, it was already committed
Date: Tue, 2 Apr 2019 14:00:51 -0300
Message-ID: <20190402170051.GA22324@alvherre.pgsql> (raw)
In-Reply-To: <20190402161320.o5wkbp7evuzqe4c2@alap3.anarazel.de>
On 2019-Apr-02, Andres Freund wrote:
> On 2019-04-02 12:51:08 -0300, Alvaro Herrera wrote:
> > AFAICS this error can only come from ExecDelete(), because the value 1
> > is TM_Invisible and the other callsites where the "unexpected
> > table_lock_tuple" error appears use different wording for that one.
>
> Hm? Why couldn't it be the ExecUpdate() case?
You're right, that one too.
> > Maybe it's the result of a deferred constraint being checked at that
> > time ... maybe it's trying to honor an "on cascade delete" setting for
> > an FK, and the affected tuple has already been updated or deleted?
>
> Then it ought to get TM_Deleted, no? We ought to wait till that
> transaction commits, and then roll back.
I was thinking that this would have happened in the same transaction;
but yeah I didn't spend too much time analyzing the exact code flow.
Anyway I agree that there's something odd going on, and perhaps you just
unmasked an earlier bug.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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: alvherre@2ndquadrant.com, andres@anarazel.de, tgl@sss.pgh.pa.us, r.zharkov@postgrespro.ru, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15727: PANIC: cannot abort transaction 295144144, it was already committed
In-Reply-To: <20190402170051.GA22324@alvherre.pgsql>
* 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