Thread: BUG #16393: PANIC: cannot abort transaction, it was already committed

The following bug has been logged on the website:

Bug reference:      16393
Logged by:          Andreas Seltenreich
Email address:      andreas.seltenreich@credativ.de
PostgreSQL version: 11.5
Operating system:   AIX
Description:

One of our customers recently experienced the following PANIC with
PostgreSQL 11.5 on AIX:

PANIC:  cannot abort transaction 1234567890, it was already committed
CONTEXT:  PL/pgSQL function foo.bar(varchar[],…,timestamptz[]) line 5 during
exception cleanup
STATEMENT:  PREPARE q1 (varchar,[...],timestamptz) AS select
foo.bar(ARRAY[$1, …], …, $101], ARRAY[$102, $103])

There is a striking similarity to BUG #15727 from 2019 where this
PANIC also occured during error handling.  Archive link to the old
bug: https://postgr.es/m/15727-0be246e7d852d229@postgresql.org

IIUC backporting was considered but deemed unreasonable here:
https://postgr.es/m/20190407203315.6v3iktksr5u3bksw@alap3.anarazel.de

Backtrace below.

regards,
Andreas

(dbx) where
abort()
pq_getmsgtext()
errposition()
IPRA.$AtCleanup_Memory()
StartTransaction()
DefineSavepoint()
IPRA.$exec_stmt_block()
pl_exec.IPRA.$exec_stmt_raise.exec_stmt()
pl_exec.IPRA.$exec_stmt_raise.IPRA.$exec_stmts()
IPRA.$exec_stmt_block()
plpgsql_exec_function()
plpgsql_call_handler()
ExecInterpExpr()
ExecEvalConstraintNotNull@AF173_67()
ExecInitProjectSet()
MultiExecProcNode()
IPRA.$InitPlan()
IPRA.$ExecBuildAggTransCall()
PortalRunFetch()

PG Bug reporting form <noreply@postgresql.org> writes:
> One of our customers recently experienced the following PANIC with
> PostgreSQL 11.5 on AIX:
> PANIC:  cannot abort transaction 1234567890, it was already committed

That's probably just a side-effect of some other problem.  There's
no strong reason to think that it's the same thing as #15727.
Can you provide a reproducer by any chance?

            regards, tom lane

Hi,

On 2020-04-27 09:19:05 +0000, PG Bug reporting form wrote:
> One of our customers recently experienced the following PANIC with
> PostgreSQL 11.5 on AIX:
> 
> PANIC:  cannot abort transaction 1234567890, it was already committed
> CONTEXT:  PL/pgSQL function foo.bar(varchar[],…,timestamptz[]) line 5 during
> exception cleanup
> STATEMENT:  PREPARE q1 (varchar,[...],timestamptz) AS select
> foo.bar(ARRAY[$1, …], …, $101], ARRAY[$102, $103])
> 
> There is a striking similarity to BUG #15727 from 2019 where this
> PANIC also occured during error handling.  Archive link to the old
> bug: https://postgr.es/m/15727-0be246e7d852d229@postgresql.org

It doesn't immediately see that similar to me. What makes you think it
is?

Greetings,

Andres Freund

Tom Lane writes:
> PG Bug reporting form <noreply@postgresql.org> writes:
>> One of our customers recently experienced the following PANIC with
>> PostgreSQL 11.5 on AIX:
>> PANIC:  cannot abort transaction 1234567890, it was already committed
>
> That's probably just a side-effect of some other problem.  There's
> no strong reason to think that it's the same thing as #15727.
> Can you provide a reproducer by any chance?

I did inquire about getting my hands on the schema or a shell to a test
instance of the database for further analysis, but it's difficult as the
system is highly guarded by our customer.  I'm afraid I won't be able to
contribute more info until then.

Andres Freund writes:
> On 2020-04-27 09:19:05 +0000, PG Bug reporting form wrote:
>> There is a striking similarity to BUG #15727 from 2019 where this
>> PANIC also occured during error handling.  Archive link to the old
>> bug: https://postgr.es/m/15727-0be246e7d852d229@postgresql.org
> It doesn't immediately see that similar to me. What makes you think it
> is?

That was just my superficial impression after looking at recipe and
backtrace of #15727 (IIRC an error occures during error handling leading
to the same panic).  I communicated to the customer that it's not clear
to me whether they are actually related but somehow I worded the bug
report with more prejudice than I intended, probably out of hope for a
quick backport fix.  Your not seeing it squashed that though :-)

thanks,
Andreas