Hi,
On 2019-04-02 12:51:08 -0300, Alvaro Herrera wrote:
> On 2019-Apr-02, Tom Lane wrote:
>
> > Andres Freund <andres@anarazel.de> writes:
> > >> 2019-04-01 15:27:38.829 +07 [7524] STATEMENT: UPDATE pgbench_accounts SET
> > >> abalance = 1 WHERE aid = 1;
> > >> 2019-04-01 15:27:38.829 +07 [7524] 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.
Greetings,
Andres Freund
