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-02T15:47:20Z
Lists: pgsql-bugs 
Hi,

On 2019-04-02 11:44:26 -0400, 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.

I suspect that's a deferred trigger. But that code obviously could throw
errors, so we gotta handle that correctly.

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.