|From:||Andres Freund <andres(at)anarazel(dot)de>|
|To:||Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>|
|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2019-04-02 12:51:08 -0300, Alvaro Herrera wrote:
> On 2019-Apr-02, Tom Lane wrote:
> > Andres Freund <andres(at)anarazel(dot)de> writes:
> > >> 2019-04-01 15:27:38.829 +07  STATEMENT: UPDATE pgbench_accounts SET
> > >> abalance = 1 WHERE aid = 1;
> > >> 2019-04-01 15:27:38.829 +07  PANIC: cannot abort transaction
> > >> 400048276, it was already committed
> > > But that's probably a separate issue.
> > What that seems to indicate is that the "unexpected table_lock_tuple
> > status" error was thrown during commit, which seems pretty odd.
> 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?
> 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. So there's something odd
happening here. I suspect there has to be some additional log output or
such to explain this.
|Next Message||Alvaro Herrera||2019-04-02 17:00:51||Re: BUG #15727: PANIC: cannot abort transaction 295144144, it was already committed|
|Previous Message||Andres Freund||2019-04-02 16:00:48||Re: BUG #15727: PANIC: cannot abort transaction 295144144, it was already committed|