Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps
 (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <pgsql-bugs-owner+archive@lists.postgresql.org>)
	id 1kxYzu-0000b8-ON
	for pgsql-bugs@arkaria.postgresql.org; Thu, 07 Jan 2021 17:22:54 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.92)
	(envelope-from <pgsql-bugs-owner+archive@lists.postgresql.org>)
	id 1kxYzr-0001CG-ST
	for pgsql-bugs@arkaria.postgresql.org; Thu, 07 Jan 2021 17:22:51 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
	by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1kxYzr-0001C8-MQ
	for pgsql-bugs@lists.postgresql.org; Thu, 07 Jan 2021 17:22:51 +0000
Received: from sss.pgh.pa.us ([66.207.139.130])
	by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1kxYzp-0000db-5c
	for pgsql-bugs@lists.postgresql.org; Thu, 07 Jan 2021 17:22:51 +0000
Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 107HMiOd208317;
	Thu, 7 Jan 2021 12:22:44 -0500
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
        james.inform@pharmapp.de,
        PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: BUG #16811: Severe reproducible server backend crash
In-reply-to: 
 <CA+hUKG+KoZFkX7YR2u31TeQPOu=1nc6EPRdVU-Pn0ohpUJdGdg@mail.gmail.com>
References: <16811-c1b599b2c6c2d622@postgresql.org>
 <CA+hUKG+KoZFkX7YR2u31TeQPOu=1nc6EPRdVU-Pn0ohpUJdGdg@mail.gmail.com>
Comments: In-reply-to Thomas Munro <thomas.munro@gmail.com>
	message dated "Thu, 07 Jan 2021 23:14:07 +1300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <208315.1610040164.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 07 Jan 2021 12:22:44 -0500
Message-ID: <208316.1610040164@sss.pgh.pa.us>
List-Id: <pgsql-bugs.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-bugs@lists.postgresql.org>
List-Owner: <mailto:pgsql-bugs-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-bugs>
Precedence: bulk

Thomas Munro <thomas.munro@gmail.com> writes:
> Thanks for the report.  I happened to have DBeaver here and could
> reproduce this, and got the following core:

I can reproduce it without anything extra.  What's needed is to run
the problematic statement in extended query mode, which you can
do like this:

$ cat foo.sql
do $$ begin rollback; end $$;

$ pgbench -n -f foo.sql -M prepared =

pgbench: error: client 0 aborted in command 0 (SQL) of script 0; perhaps t=
he backend died while processing

That lnext() should certainly not find pstmt->stmts to be NIL,
seeing that we are inside a loop over that list.  Ergo, something
is clobbering this active portal.  A bit of gdb'ing says the clobber
happens here:

#0  AtAbort_Portals () at portalmem.c:833
    (this appears to be inlined code from PortalReleaseCachedPlan)
#1  0x00000000005a4ce2 in AbortTransaction () at xact.c:2711
#2  0x00000000005a55d5 in AbortCurrentTransaction () at xact.c:3322
#3  0x00000000006d1557 in _SPI_rollback (chain=3D<optimized out>) at spi.c=
:326
#4  0x00007feef9e851c5 in exec_stmt_rollback (stmt=3D0x2babca8, =

    estate=3D0x7fff35e55ee0) at pl_exec.c:4961
#5  exec_stmts (estate=3D0x7fff35e55ee0, stmts=3D0x2babd80) at pl_exec.c:2=
081
#6  0x00007feef9e863cb in exec_stmt_block (estate=3D0x7fff35e55ee0, =

    block=3D0x2babdd8) at pl_exec.c:1904
#7  0x00007feef9e864bb in exec_toplevel_block (
    estate=3Destate@entry=3D0x7fff35e55ee0, block=3D0x2babdd8) at pl_exec.=
c:1602
#8  0x00007feef9e86ced in plpgsql_exec_function (func=3Dfunc@entry=3D0x2ba=
7c60, =

    fcinfo=3Dfcinfo@entry=3D0x7fff35e56060, =

    simple_eval_estate=3Dsimple_eval_estate@entry=3D0x2bad6b0, =

    simple_eval_resowner=3Dsimple_eval_resowner@entry=3D0x2b12e40, =

    atomic=3D<optimized out>) at pl_exec.c:605
#9  0x00007feef9e8fd58 in plpgsql_inline_handler (fcinfo=3D<optimized out>=
)
    at pl_handler.c:344
#10 0x000000000091a540 in FunctionCall1Coll (flinfo=3D0x7fff35e561f0, =

    collation=3D<optimized out>, arg1=3D<optimized out>) at fmgr.c:1141
#11 0x000000000091aaa9 in OidFunctionCall1Coll (functionId=3D<optimized ou=
t>, =

    collation=3Dcollation@entry=3D0, arg1=3D45120272) at fmgr.c:1419
#12 0x000000000064df7e in ExecuteDoStmt (stmt=3Dstmt@entry=3D0x2b07ed8, =

    atomic=3Datomic@entry=3Dfalse) at functioncmds.c:2027
#13 0x000000000080fa14 in standard_ProcessUtility (pstmt=3D0x2b07e40, =

    queryString=3D0x2b079a0 "do $$ begin rollback; end $$;", =

    context=3DPROCESS_UTILITY_TOPLEVEL, params=3D0x0, queryEnv=3D0x0, =

    dest=3D0xa90540 <donothingDR>, qc=3D0x7fff35e56630) at utility.c:696
#14 0x000000000080d044 in PortalRunUtility (portal=3D0x2b47240, pstmt=3D0x=
2b07e40, =

    isTopLevel=3D<optimized out>, setHoldSnapshot=3D<optimized out>, =

    dest=3D0xa90540 <donothingDR>, qc=3D0x7fff35e56630) at pquery.c:1159
#15 0x000000000080db24 in PortalRunMulti (portal=3Dportal@entry=3D0x2b4724=
0, =

    isTopLevel=3DisTopLevel@entry=3Dtrue, =

    setHoldSnapshot=3DsetHoldSnapshot@entry=3Dfalse, dest=3D0xa90540 <dono=
thingDR>, =

    dest@entry=3D0x2adfa88, altdest=3D0xa90540 <donothingDR>, =

    altdest@entry=3D0x2adfa88, qc=3Dqc@entry=3D0x7fff35e56630) at pquery.c=
:1311
#16 0x000000000080e937 in PortalRun (portal=3Dportal@entry=3D0x2b47240, =

    count=3Dcount@entry=3D9223372036854775807, isTopLevel=3DisTopLevel@ent=
ry=3Dtrue, =

    run_once=3Drun_once@entry=3Dtrue, dest=3Ddest@entry=3D0x2adfa88, =

    altdest=3Daltdest@entry=3D0x2adfa88, qc=3D0x7fff35e56630) at pquery.c:=
779
#17 0x000000000080c77b in exec_execute_message (max_rows=3D922337203685477=
5807, =

    portal_name=3D0x2adf670 "") at postgres.c:2196
#18 PostgresMain (argc=3Dargc@entry=3D1, argv=3Dargv@entry=3D0x7fff35e569c=
0, =

    dbname=3D<optimized out>, username=3D<optimized out>) at postgres.c:44=
52

So I would say that the conditions under which AtAbort_Portals
decides that it can destroy a portal rather than just mark it failed
need to be reconsidered.  It's not clear to me exactly how that
should change though.  Maybe Peter has more insight.

			regards, tom lane