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: /messages/by-id/15727-0be246e7d852d229@postgresql.org
IIUC backporting was considered but deemed unreasonable here:
/messages/by-id/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: /messages/by-id/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 committedThat'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: /messages/by-id/15727-0be246e7d852d229@postgresql.orgIt 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