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
Subject: Re: BUG #15727: PANIC: cannot abort transaction 295144144,
 it was already committed
In-reply-to: <b5d89910ec01a657530d1a49ff0e05dc@postgrespro.ru>
References: <30650.1554219866@sss.pgh.pa.us>
 <20190402155108.GA17787@alvherre.pgsql>
 <20190402161320.o5wkbp7evuzqe4c2@alap3.anarazel.de>
 <b5d89910ec01a657530d1a49ff0e05dc@postgrespro.ru>
Comments: In-reply-to r.zharkov@postgrespro.ru
	message dated "Wed, 03 Apr 2019 00:04:15 +0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1491.1554225238.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 02 Apr 2019 13:13:58 -0400
Message-ID: <1492.1554225238@sss.pgh.pa.us>
Precedence: bulk

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 ta=
ble_lock_tuple status: %u", test);
pgsql/src/backend/executor/nodeLockRows.c: 232: 				elog(ERROR, "unexpecte=
d table_lock_tuple status: %u",
pgsql/src/backend/executor/nodeModifyTable.c: 881: 							elog(ERROR, "une=
xpected table_lock_tuple status: %u",
pgsql/src/backend/executor/nodeModifyTable.c: 1384: 							elog(ERROR, "un=
expected table_lock_tuple status: %u",
pgsql/src/backend/executor/execReplication.c: 211: 				elog(ERROR, "unexpe=
cted table_lock_tuple status: %u", res);
pgsql/src/backend/executor/execReplication.c: 375: 				elog(ERROR, "unexpe=
cted table_lock_tuple status: %u", res);


			regards, tom lane