From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, r(dot)zharkov(at)postgrespro(dot)ru, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #15727: PANIC: cannot abort transaction 295144144, it was already committed |
Date: | 2019-04-02 17:00:51 |
Message-ID: | 20190402170051.GA22324@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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
From | Date | Subject | |
---|---|---|---|
Next Message | r.zharkov | 2019-04-02 17:04:15 | Re: BUG #15727: PANIC: cannot abort transaction 295144144, it was already committed |
Previous Message | Andres Freund | 2019-04-02 16:13:20 | Re: BUG #15727: PANIC: cannot abort transaction 295144144, it was already committed |