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
In-reply-to: <18172-9b8c5fc1d676ded3@postgresql.org>
References: <18172-9b8c5fc1d676ded3@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Fri, 27 Oct 2023 11:02:14 -0000"
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0"
Content-ID: <1736330.1698463109.0@sss.pgh.pa.us>
Date: Fri, 27 Oct 2023 23:19:02 -0400
Message-ID: <1736370.1698463142@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1736370.1698463142%40sss.pgh.pa.us>
Precedence: bulk

------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1736330.1698463109.1@sss.pgh.pa.us>

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


------- =_aaaaaaaaaa0
Content-Type: text/x-diff;
	name="v1-fix-zero-rows-leak-in-ExecProjectSet.patch";
	charset="us-ascii"
Content-ID: <1736330.1698463109.2@sss.pgh.pa.us>
Content-Description: v1-fix-zero-rows-leak-in-ExecProjectSet.patch
Content-Transfer-Encoding: quoted-printable

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.
 		 */

------- =_aaaaaaaaaa0--