Re: Server closed the connection unexpectedly (memory leak)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Zu-Ming Jiang <zuming(dot)jiang(at)inf(dot)ethz(dot)ch>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: Server closed the connection unexpectedly (memory leak)
Date: 2023-06-24 16:56:06
Message-ID: 229225.1687625766@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Zu-Ming Jiang <zuming(dot)jiang(at)inf(dot)ethz(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2023-06-24 18:33:27 BUG #17995: Segmentation fault caused by UPDATE statement
Previous Message Dmitry Dolgov 2023-06-24 13:59:10 Re: BUG #17949: Adding an index introduces serialisation anomalies.