Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: r.zharkov@postgrespro.ru, pgsql-bugs@lists.postgresql.org
Date: 2019-04-02T15:44:26Z
Lists: pgsql-bugs 
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.

			regards, tom lane

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.