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, Alvaro Herrera <alvherre@2ndquadrant.com>, pgsql-bugs@lists.postgresql.org
Date: 2019-04-02T17:17:14Z
Lists: pgsql-bugs 
Hi,

On 2019-04-02 13:13:58 -0400, Tom Lane wrote:
> FWIW, I see six potential candidates, not two:
> 
> pgsql/src/backend/commands/trigger.c: 3380: 				elog(ERROR, "unexpected table_lock_tuple status: %u", test);
> pgsql/src/backend/executor/nodeLockRows.c: 232: 				elog(ERROR, "unexpected table_lock_tuple status: %u",
> pgsql/src/backend/executor/execReplication.c: 211: 				elog(ERROR, "unexpected table_lock_tuple status: %u", res);
> pgsql/src/backend/executor/execReplication.c: 375: 				elog(ERROR, "unexpected table_lock_tuple status: %u", res);

These have an explicit case / separate error for TM_Invisible (= 1 -
which is the status we're seeing according to the error message)
though. So afaict they can't be relevant here.

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.