Re: list_free in addRangeTableEntryForJoin
От | Ranier Vilela |
---|---|
Тема | Re: list_free in addRangeTableEntryForJoin |
Дата | |
Msg-id | CAEudQAqf35FN_gqinuxjWpeT6m0_Q9gQJkE3qGA5HUMEXceYhw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: list_free in addRangeTableEntryForJoin (Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>) |
Список | pgsql-hackers |
Em seg., 10 de jun. de 2024 às 10:45, Ilia Evdokimov <ilya.evdokimov@tantorlabs.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
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
В списке pgsql-hackers по дате отправления: