Re: BUG #18172: High memory usage in tSRF function context

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>

To: sk@zsrv.org

Cc: pgsql-bugs@lists.postgresql.org

Date: 2023-10-28T03:19:02Z

Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Fix intra-query memory leak when a SRF returns zero rows.
- 237f8765dfd9 17.0 landed
- d8d7f282fd1d 12.17 landed
- b7684473d74a 13.13 landed
- 7ab6971c657f 11.22 landed
- 5d7515d7d116 14.10 landed
- 592cb11fbee0 15.5 landed
- 07494a0df9a6 16.1 landed
Adjust parallel_schedule with event triggers on authenticated login
- 83510534d5f3 17.0 cited

Attachments

v1-fix-zero-rows-leak-in-ExecProjectSet.patch (text/x-diff) patch v1

PG Bug reporting form <noreply@postgresql.org> writes:
> While researching several cases of OOM, I discovered an atypically high
> memory consumption in this case:
> ...
> The first query consumes much more memory; note that it refers to a
> non-existent json key. Querying for a key that exists in JSON or checking
> for the existence of a key in where clause corrects memory consumption.

Thanks for the report!  It seems that ExecProjectSet neglected to
think hard about what happens when the SRF returns zero rows, so
it leaks whatever memory the SRF expression might have leaked.
The attached fixes it for me.

			regards, tom lane