Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h6dZo-0004Bg-SQ for pgsql-bugs@arkaria.postgresql.org; Wed, 20 Mar 2019 15:56:25 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1h6dZm-0007uI-LX for pgsql-bugs@arkaria.postgresql.org; Wed, 20 Mar 2019 15:56:22 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h6dZm-0007u7-BG for pgsql-bugs@lists.postgresql.org; Wed, 20 Mar 2019 15:56:22 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h6dZj-00011v-GH for pgsql-bugs@lists.postgresql.org; Wed, 20 Mar 2019 15:56:21 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id x2KFuDrs008679; Wed, 20 Mar 2019 11:56:13 -0400 From: Tom Lane To: julian.schauder@gmx.de cc: pgsql-bugs@lists.postgresql.org, Peter Eisentraut Subject: Re: BUG #15703: Segfault in cancelled CALL-Statements In-reply-to: <15703-c12c5bc0ea34ba26@postgresql.org> References: <15703-c12c5bc0ea34ba26@postgresql.org> Comments: In-reply-to PG Bug reporting form message dated "Tue, 19 Mar 2019 10:04:55 -0000" MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <8605.1553097219.0@sss.pgh.pa.us> Date: Wed, 20 Mar 2019 11:56:13 -0400 Message-ID: <8678.1553097373@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8605.1553097219.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable PG Bug reporting form writes: > there seems to be a SEGFAULT issue with CALL-Procedures once they get > SIGINT'ed. What I'm seeing in an assert-enabled build is an assertion failure: TRAP: FailedAssertion("!(portal->resowner =3D=3D ((void *)0))", File: "por= talmem.c"\ , Line: 874) #0 0x00007fbe9cd6beab in raise () from /lib64/libc.so.6 #1 0x00007fbe9cd565b9 in abort () from /lib64/libc.so.6 #2 0x000000000089d9cf in ExceptionalCondition (conditionName=3DconditionN= ame@entry=3D0xac34b0 "!(portal->resowner =3D=3D ((void *)0))", = errorType=3DerrorType@entry=3D0x8ec7c9 "FailedAssertion", fileName=3Df= ileName@entry=3D0xac3163 "portalmem.c", lineNumber=3DlineNumber@entry=3D87= 4) at assert.c:54 #3 0x00000000008ca924 in AtCleanup_Portals () at portalmem.c:874 #4 0x00000000005145c7 in CleanupTransaction () at xact.c:2676 #5 0x00000000005186ca in AbortCurrentTransaction () at xact.c:3133 #6 0x0000000000789004 in PostgresMain (argc=3D1, argv=3Dargv@entry=3D0x2b= c3ad0, dbname=3D, username=3D0x2b96518 "tgl") at postgres.c= :4033 #7 0x000000000070d91f in BackendRun (port=3D0x2bbce20, port=3D0x2bbce20) = at postmaster.c:4399 #8 BackendStartup (port=3D0x2bbce20) at postmaster.c:4090 #9 ServerLoop () at postmaster.c:1703 #10 0x000000000070e81e in PostmasterMain (argc=3Dargc@entry=3D2, argv=3Dar= gv@entry=3D0x2b944c0) at postmaster.c:1376 #11 0x000000000047acae in main (argc=3D2, argv=3D0x2b944c0) at main.c:228 (gdb) f 3 #3 0x00000000008ca924 in AtCleanup_Portals () at portalmem.c:874 874 Assert(portal->resowner =3D=3D NULL); (gdb) p *portal $1 =3D {name =3D 0x2bff4b8 "", prepStmtName =3D 0x0, por= talContext =3D 0x2c728a0, resowner =3D 0x2c141d0, cleanup =3D 0x0, createS= ubid =3D 1, = activeSubid =3D 1, sourceText =3D 0x2c729b8 "SELECT GENERATE_SERIES(1,10= 0000)", commandTag =3D 0xa10eb3 "SELECT", stmts =3D 0x2c74e30, = cplan =3D 0x2c75520, portalParams =3D 0x0, queryEnv =3D 0x0, strategy =3D= PORTAL_ONE_SELECT, cursorOptions =3D 4, run_once =3D false, = status =3D PORTAL_FAILED, portalPinned =3D true, autoHeld =3D true, quer= yDesc =3D 0x0, tupDesc =3D 0x2c84118, formats =3D 0x0, holdStore =3D 0x2c8= 3ee8, = holdContext =3D 0x2c83dd0, holdSnapshot =3D 0x0, atStart =3D false, atEn= d =3D false, portalPos =3D 10, creation_time =3D 606411039547087, visible = =3D true} Poking around a bit, it seems like this is a thinko in HoldPinnedPortals: it's not considering the possibility of a failure during HoldPortal(). In your test the failure is triggered by query cancel, but an ordinary execution error while finishing out a cursor's calculations would be a problem too. I think it should not mark the portal as autoHeld until it's been successfully held. The attached patch seems to make the problem go away for me --- can you confirm it fixes your original issue? I find HoldPinnedPortals suspicious in another way: is it really OK for it to mark *all* pinned portals as auto-held? What if we're in a nest of procedures run by different PLs (of which only the innermost will have any idea we're committing)? Will the right things happen if we auto-hold a portal or two and then get a failure on another one? regards, tom lane ------- =_aaaaaaaaaa0 Content-Type: text/x-diff; name="auto-held-portal-fix.patch"; charset="us-ascii" Content-ID: <8605.1553097219.2@sss.pgh.pa.us> Content-Description: auto-held-portal-fix.patch Content-Transfer-Encoding: quoted-printable diff --git a/src/backend/utils/mmgr/portalmem.c b/src/backend/utils/mmgr/p= ortalmem.c index a92b4541bd..697c980282 100644 --- a/src/backend/utils/mmgr/portalmem.c +++ b/src/backend/utils/mmgr/portalmem.c @@ -1262,8 +1262,8 @@ HoldPinnedPortals(void) (errcode(ERRCODE_INVALID_TRANSACTION_TERMINATION), errmsg("cannot perform transaction commands inside a cursor loop t= hat is not read-only"))); = - portal->autoHeld =3D true; HoldPortal(portal); + portal->autoHeld =3D true; } } } ------- =_aaaaaaaaaa0--