Re: A potential memory leak on Merge Join when Sort node is not below Materialize node

Поиск
Список
Период
Сортировка
От Ronan Dunklau
Тема Re: A potential memory leak on Merge Join when Sort node is not below Materialize node
Дата
Msg-id 2254070.ElGaqSPkdT@aivenronan
обсуждение исходный текст
Ответ на Re: A potential memory leak on Merge Join when Sort node is not below Materialize node  (David Rowley <dgrowleyml@gmail.com>)
Ответы Re: A potential memory leak on Merge Join when Sort node is not below Materialize node
Список pgsql-hackers
> I've just pushed the disable byref Datums patch I posted earlier. I
> only made a small adjustment to make use of the TupleDescAttr() macro.
> Önder, thank you for the report.

Thank you David for taking care of this.

> Yeah, I think the same rules around scope apply as
> tuplesort_gettupleslot() with copy==false.  We could do it by adding a
> copy flag to the existing function, but I'd rather not add the
> branching to that function. It's probably just better to duplicate it
> and adjust.
>

For the record, I tried to see if gcc would optimize the function by
generating two different versions when copy is true or false, thus getting rid
of the branching while still having only one function to deal with. Using the
-fipa-cp-clone (or even the whole set of additional flags coming with -O3), it
does generate a special-case version of the function, but it seems to then
only be used by heapam_index_validate_scan and
percentile_cont_multi_final_common. This is from my investigation looking for
references to the specialized version in the DWARF debug information.

Regards,

--
Ronan Dunklau





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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Avoid memory leaks during base backups
Следующее
От: Tom Lane
Дата:
Сообщение: Re: A potential memory leak on Merge Join when Sort node is not below Materialize node