Horton

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

Alvaro Herrera <alvherre@2ndquadrant.com>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: r.zharkov@postgrespro.ru, Andres Freund <andres@anarazel.de>, pgsql-bugs@lists.postgresql.org
Date: 2019-04-02T17:17:21Z
Lists: pgsql-bugs 
On 2019-Apr-02, 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/nodeModifyTable.c: 881: 							elog(ERROR, "unexpected table_lock_tuple status: %u",
> pgsql/src/backend/executor/nodeModifyTable.c: 1384: 							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);

The other four handle the TM_Invisible case with a different error
message.  Anyway, the six of them are unexpected so changing them all to
PANIC ought to be good enough.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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.