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:51:38Z
Lists: pgsql-bugs 
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.

			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.