Horton

Re: BUG #15727: PANIC: cannot abort transaction 295144144, it was already committed

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: r.zharkov@postgrespro.ru, pgsql-bugs@lists.postgresql.org
Date: 2019-04-02T16:00:48Z
Lists: pgsql-bugs 
Hi,

On 2019-04-02 11:51:38 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2019-04-02 11:44:26 -0400, Tom Lane wrote:
> >> What that seems to indicate is that the "unexpected table_lock_tuple
> >> status" error was thrown during commit, which seems pretty odd.
> 
> > I suspect that's a deferred trigger. But that code obviously could throw
> > errors, so we gotta handle that correctly.
> 
> Deferred triggers execute before the real transaction commit, not during
> the critical section surrounding where we set the bit in pg_clog.
> But this error is seemingly getting thrown from within that critical
> section, otherwise we wouldn't have inconsistent xact status afterwards.

I don't think it was thrown during the critical section - we'd otherwise
see the ERROR about unexpected lock status converted to a PANIC (and the
"cannot abort transaction, already committed" is a PANIC itself).  I
suspect it's more likely that we corrupt the xact.c status somewhere -
but it's hard to say without knowing more about the workload.

Greetings,

Andres Freund

Commits

  1. Fix GetNewTransactionId()'s interaction with xidVacLimit.

  2. Fix example in comment.

  3. Fix EvalPlanQualStart to handle partitioned result rels correctly.

  4. Fix a number of issues around modifying a previously updated row.

  5. Use FullTransactionId for the transaction stack.

  6. Add basic infrastructure for 64 bit transaction IDs.

  7. tableam: Add tuple_{insert, delete, update, lock} and use.

  8. Throw error if expiring tuple is again updated or deleted.