Re: list_free in addRangeTableEntryForJoin

Поиск
Список
Период
Сортировка
От Ilia Evdokimov
Тема Re: list_free in addRangeTableEntryForJoin
Дата
Msg-id 9d3dbecc-ee7b-419c-aad3-3ef1b098540e@tantorlabs.com
обсуждение исходный текст
Ответ на Re: list_free in addRangeTableEntryForJoin  (Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>)
Ответы Re: list_free in addRangeTableEntryForJoin
Список pgsql-hackers
 >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, 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.

Thanks for reviewing. I'm looking forward to new suggestions.

Regards,

Ilia Evdokimov,

Tantor Labs LCC

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Reuse child_relids in try_partitionwise_join was Re: Assert failure on bms_equal(child_joinrel->relids, child_joinrelids)
Следующее
От: vignesh C
Дата:
Сообщение: Re: confirmed flush lsn seems to be move backward in certain error cases