Re: list_free in addRangeTableEntryForJoin

Em seg., 10 de jun. de 2024 às 10:45, Ilia Evdokimov <
ilya(dot)evdokimov(at)tantorlabs(dot)com> escreveu:

> >Now you need to analyze whether the memory in question is not managed
> by a Context
> I've already analyzed. Let's explain details:
>
>
> 1. analyze.c
> 1718: List* targetnames;
> 1815: targetnames = NIL;
> 1848: targetnames = lappend(targetnames, makeString(colName));
> 1871: addRangeTableEntryForJoin(...);
> => list_free(targetnames);
>
> 2. parse_clause.c
> 1163: List* res_colnames;
> 1289: res_colnames = NIL;
> 1324: foreach(col, res_colnames);
> 1396: res_colnames = lappend(res_colnames, lfirst(ucol));
> 1520, 1525: extractRemainingColumns(...);
> |
> 290: *res_colnames = lappend(*res_colnames, lfirst(lc));
> 1543: addRangeTableEntryForJoin(...);
> => list_free(res_colnames);
>
>
> As you can see, there are no other pointers working with this block of
> memory,

You can see this line?
sortnscolumns = (ParseNamespaceColumn *)
palloc0

All allocations in the backend occur at Context memory managers.
Resource leak can occur mainly with TopTransactionContext.

> and all operations above are either read-only or append nodes to
> the lists. If I am mistaken, please correct me.
> Furthermore, I will call `list_free` immediately after
> `addRangeTableEntryForJoin()`. The new patch is attached.
>
This style is not recommended.
You prevent the use of colnames after calling addRangeTableEntryForJoin.

Better free at the end of the function, like 0002.

Tip 0001, 0002, 0003 numerations are to different patchs.
v1, v2, v3 are new versions of the same patch.

best regards,
Ranier Vilela