MuhammadTahaNaveed commented on code in PR #2517:
URL: https://github.com/apache/age/pull/2517#discussion_r3820973266
##########
src/backend/executor/cypher_merge.c:
##########
@@ -690,6 +717,9 @@ static TupleTableSlot *exec_cypher_merge(CustomScanState
*node)
TupleTableSlot *projected;
HeapTuple htup;
+ /* Release scratch retained by the preceding input row. */
+ ResetExprContext(econtext);
Review Comment:
This resets the row context, but duplicate paths still appear to retain the
pointer array allocated by `prebuild_path()`, since `free_path_entry_array()`
only frees its entries. Could you check the cleanup in both duplicate branches?
##########
src/backend/executor/cypher_set.c:
##########
@@ -415,6 +418,13 @@ void apply_update_list(CustomScanState *node,
HASHCTL hashctl;
HTAB *index_cache = NULL;
HASHCTL idx_hashctl;
+ MemoryContext old_context;
+
+ /*
+ * All callers reset this context before processing the next input row.
+ * Keep transient update state here so it has the same bounded lifetime.
+ */
+ old_context = MemoryContextSwitchTo(econtext->ecxt_per_tuple_memory);
Review Comment:
I still see memory scaling with row count when the label has a stored
generated column. Could you check whether all generated-column scratch is
covered by this reset?
##########
src/backend/executor/cypher_delete.c:
##########
@@ -149,6 +149,9 @@ static TupleTableSlot *exec_cypher_delete(CustomScanState
*node)
*/
while(true)
{
+ /* Release scratch retained by the preceding input row. */
+ ResetExprContext(econtext);
Review Comment:
Does this also cover the connected-edge RLS checks performed later during
DELETE cleanup? Those checks appear to reuse the expression context without
resetting it between edges.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
