pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  

help / color / mirror / Atom feed

From: Tom Lane <tgl@sss.pgh.pa.us>
To: sk@zsrv.org
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18172: High memory usage in tSRF function context
Date: Fri, 27 Oct 2023 23:19:02 -0400
Message-ID: <1736370.1698463142@sss.pgh.pa.us> (raw)
In-Reply-To: <18172-9b8c5fc1d676ded3@postgresql.org>
References: <18172-9b8c5fc1d676ded3@postgresql.org>

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

Attachments:

v1-fix-zero-rows-leak-in-ExecProjectSet.patch (text/x-diff, 1.3K) download
diff --git a/src/backend/executor/nodeProjectSet.c b/src/backend/executor/nodeProjectSet.c
index b4bbdc89b1..307ac591be 100644
--- a/src/backend/executor/nodeProjectSet.c
+++ b/src/backend/executor/nodeProjectSet.c
@@ -72,20 +72,22 @@ ExecProjectSet(PlanState *pstate)
 			return resultSlot;
 	}
 
-	/*
-	 * Reset argument context to free any expression evaluation storage
-	 * allocated in the previous tuple cycle.  Note this can't happen until
-	 * we're done projecting out tuples from a scan tuple, as ValuePerCall
-	 * functions are allowed to reference the arguments for each returned
-	 * tuple.
-	 */
-	MemoryContextReset(node->argcontext);
-
 	/*
 	 * Get another input tuple and project SRFs from it.
 	 */
 	for (;;)
 	{
+		/*
+		 * Reset argument context to free any expression evaluation storage
+		 * allocated in the previous tuple cycle.  Note this can't happen
+		 * until we're done projecting out tuples from a scan tuple, as
+		 * ValuePerCall functions are allowed to reference the arguments for
+		 * each returned tuple.  However, if we loop around after finding that
+		 * no rows are produced from a scan tuple, we should reset, as the SRF
+		 * might well leak memory in that case.
+		 */
+		MemoryContextReset(node->argcontext);
+
 		/*
 		 * Retrieve tuples from the outer plan until there are no more.
 		 */

view thread (5+ messages)  latest in thread

Message-ID: <1736370.1698463142@sss.pgh.pa.us>
Permalink:  ../1736370.1698463142@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/1736370.1698463142@sss.pgh.pa.us

copy link · copy postgr.es · copy git am

reply

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, sk@zsrv.org, pgsql-bugs@lists.postgresql.org
  Subject: Re: BUG #18172: High memory usage in tSRF function context
  In-Reply-To: <1736370.1698463142@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