From: Tom Lane <tgl@sss.pgh.pa.us>
To: Zu-Ming Jiang <zuming.jiang@inf.ethz.ch>
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: Server closed the connection unexpectedly (memory leak)
In-reply-to: <08f7224c-2de9-0996-549a-c9e9d806fdef@inf.ethz.ch>
References: <08f7224c-2de9-0996-549a-c9e9d806fdef@inf.ethz.ch>
Comments: In-reply-to Zu-Ming Jiang <zuming.jiang@inf.ethz.ch>
	message dated "Fri, 23 Jun 2023 18:06:34 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <229224.1687625766.1@sss.pgh.pa.us>
Date: Sat, 24 Jun 2023 12:56:06 -0400
Message-ID: <229225.1687625766@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/229225.1687625766%40sss.pgh.pa.us>
Precedence: bulk

Zu-Ming Jiang <zuming.jiang@inf.ethz.ch> writes:
> My fuzzer finds a bug in Postgres, which makes the connection closed 
> unexpectedly.

TBH, I think there's not much to be learned here, beyond "a
ridiculously complicated query takes a ridiculous amount of memory
to plan".  The reason for the backend crash is presumably that the
OOM killer decided to zap it.  If you run the postmaster under a
"ulimit -v" setting that's small enough to act before the OOM killer
does, then you get an unexciting "out of memory" error.

I did find that if you mark cte_3 as MATERIALIZED, the resource
consumption is a lot less --- but you get a plan that requires
41191 lines to EXPLAIN, so it's still way outside any bounds of
reasonability.  Perhaps there's room there to argue that we
shouldn't flatten CTE subqueries that are "too big" ... but it's
hard to decide how to measure "too big".

			regards, tom lane