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)
Date: Sat, 24 Jun 2023 12:56:06 -0400
Message-ID: <229225.1687625766@sss.pgh.pa.us> (raw)
In-Reply-To: <08f7224c-2de9-0996-549a-c9e9d806fdef@inf.ethz.ch>
References: <08f7224c-2de9-0996-549a-c9e9d806fdef@inf.ethz.ch>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, zuming.jiang@inf.ethz.ch, pgsql-bugs@lists.postgresql.org
Subject: Re: Server closed the connection unexpectedly (memory leak)
In-Reply-To: <229225.1687625766@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox