pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Жарков Роман <r.zharkov@postgrespro.ru>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15727: PANIC: cannot abort transaction 295144144, it was already committed
Date: Wed, 3 Apr 2019 00:35:47 +0700
Message-ID: <2BD617B6-CC34-42EF-8D79-4669C5DFB8D1@postgrespro.ru> (raw)
In-Reply-To: <1492.1554225238@sss.pgh.pa.us>
References: <30650.1554219866@sss.pgh.pa.us>
	<20190402155108.GA17787@alvherre.pgsql>
	<20190402161320.o5wkbp7evuzqe4c2@alap3.anarazel.de>
	<b5d89910ec01a657530d1a49ff0e05dc@postgrespro.ru>
	<1492.1554225238@sss.pgh.pa.us>



> 3 апр. 2019 г., в 0:13, Tom Lane <tgl@sss.pgh.pa.us> написал(а):
> 
> 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

Ok. I will made it tomorrow morning.

regards,
Roman Zharkov





view thread (46+ messages)  latest in thread

Message-ID: <2BD617B6-CC34-42EF-8D79-4669C5DFB8D1@postgrespro.ru>
Permalink:  ../2BD617B6-CC34-42EF-8D79-4669C5DFB8D1@postgrespro.ru/
Also on:    postgresql.org/message-id/2BD617B6-CC34-42EF-8D79-4669C5DFB8D1@postgrespro.ru

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: r.zharkov@postgrespro.ru, tgl@sss.pgh.pa.us, andres@anarazel.de, alvherre@2ndquadrant.com, pgsql-bugs@lists.postgresql.org
  Subject: Re: BUG #15727: PANIC: cannot abort transaction 295144144, it was already committed
  In-Reply-To: <2BD617B6-CC34-42EF-8D79-4669C5DFB8D1@postgrespro.ru>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox