From: Tom Lane <tgl@sss.pgh.pa.us>
To: "=?UTF-8?B?6LW15bqt5rW3KOW6reeroCk=?=" <zhaotinghai.zth@alibaba-inc.com>
cc: "pgsql-hackers" <pgsql-hackers@lists.postgresql.org>,
        Jeff Davis <pgsql@j-davis.com>, Heikki Linnakangas <hlinnaka@iki.fi>
Subject: Re: sublink [exists (select xxx group by grouping sets ())] causes an
 assertion error
In-reply-to: 
 <cfd84cb8-12fe-433a-a4bb-f460a4515f9c.zhaotinghai.zth@alibaba-inc.com>
References: 
 <cfd84cb8-12fe-433a-a4bb-f460a4515f9c.zhaotinghai.zth@alibaba-inc.com>
Comments: In-reply-to "=?UTF-8?B?6LW15bqt5rW3KOW6reeroCk=?="
 <zhaotinghai.zth@alibaba-inc.com>
	message dated "Fri, 22 Mar 2024 16:54:49 +0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <932663.1711124920.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 22 Mar 2024 12:28:40 -0400
Message-ID: <932664.1711124920@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/932664.1711124920%40sss.pgh.pa.us>
Precedence: bulk

"=3D?UTF-8?B?6LW15bqt5rW3KOW6reeroCk=3D?=3D" <zhaotinghai.zth@alibaba-inc.=
com> writes:
> I recently notice these sql can lead to a assertion error in pg14 and ol=
der version. Here is an example:
> postgres=3D> CREATE TABLE t1 (a int);
> postgres=3D> INSERT INTO t1 VALUES (1);
> postgres=3D> SELECT EXISTS ( SELECT * FROM t1 GROUP BY GROUPING SETS ((a=
), generate_series (1, 262144)) ) AS result;
> server closed the connection unexpectedly

In current v14 this produces:
TRAP: FailedAssertion("!lt->writing || lt->buffer =3D=3D NULL", File: "log=
tape.c", Line: 1279, PID: 928622)

Thanks for the report.  I did some bisecting and found that the crash
appears at Jeff's commit c8aeaf3ab (which introduced this assertion)
and disappears at Heikki's c4649cce3 (which removed it).  So I would
say that the problem is "this assertion is wrong", and we should fix
the problem by fixing the assertion, not by hacking around in distant
calling code.  On the whole, since this code has been dead for
several versions, I'd be inclined to just remove the assertion.
I think it's quite risky because of the possibility that we reach
this function during post-transaction-abort cleanup, when there's
no very good reason to assume that the tapeset's been closed down
cleanly.  (To be clear, that's not what's happening in the given
test case ... but I fear that it could.)

			regards, tom lane