Fix intra-query memory leak when a SRF returns zero rows.
authorTom Lane <[email protected]>
Sat, 28 Oct 2023 18:04:43 +0000 (14:04 -0400)
committerTom Lane <[email protected]>
Sat, 28 Oct 2023 18:04:43 +0000 (14:04 -0400)
When looping around after finding that the set-returning function
returned zero rows for the current input tuple, ExecProjectSet
neglected to reset either of the two memory contexts it's
responsible for cleaning out.  Typically this wouldn't cause much
problem, because once the SRF does return at least one row, the
contexts would get reset on the next call.  However, if the SRF
returns no rows for many input tuples in succession, quite a lot
of memory could be transiently consumed.

To fix, make sure we reset both contexts while looping around.

Per bug #18172 from Sergei Kornilov.  Back-patch to all supported
branches.

Discussion: https://postgr.es/m/18172-9b8c5fc1d676ded3@postgresql.org

src/backend/executor/nodeProjectSet.c

index 6d6ed38ceeb45a4e12fe9a1022e96d0fe5c4b3ce..b0988fd064faa8ef7bcb19a38dccbb36c88a8ae0 100644 (file)
@@ -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, to avoid
+        * leaking memory when many successive scan tuples produce no rows.
+        */
+       MemoryContextReset(node->argcontext);
+
        /*
         * Retrieve tuples from the outer plan until there are no more.
         */
@@ -111,6 +113,12 @@ ExecProjectSet(PlanState *pstate)
         */
        if (resultSlot)
            return resultSlot;
+
+       /*
+        * When we do loop back, we'd better reset the econtext again, just in
+        * case the SRF leaked some memory there.
+        */
+       ResetExprContext(econtext);
    }
 
    return NULL;