Обсуждение: BUG #16393: PANIC: cannot abort transaction, it was already committed
BUG #16393: PANIC: cannot abort transaction, it was already committed
От
PG Bug reporting form
Дата:
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
Re: BUG #16393: PANIC: cannot abort transaction, it was already committed
От
Andreas Seltenreich
Дата:
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