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: r.zharkov@postgrespro.ru
Cc: Andres Freund <andres@anarazel.de>, Alvaro Herrera <alvherre@2ndquadrant.com>, pgsql-bugs@lists.postgresql.org
Date: 2019-04-02T17:13:58Z
Lists: pgsql-bugs 
r.zharkov@postgrespro.ru writes:
> I made the new core file:

Thanks, but this isn't much help --- it just shows what we already
know, ie the "cannot abort transaction" error occurs after some other
error was thrown.

What would be more helpful would be to adjust the places that
can throw the "unexpected table_lock_tuple status" error text to be
PANIC rather than ERROR, so that the core dump would show a stack
trace showing how we got to whichever of those places this is.
Or, run the test with a higher log verbosity, so that you can find
out which of those places is throwing the error to begin with;
then just PANIC-ize that one.

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);


			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.