Re: BUG #15727: PANIC: cannot abort transaction 295144144, it was already committed - Mailing list 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_tuplestatus: %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