Re: A potential memory leak on Merge Join when Sort node is not below Materialize node - Mailing list pgsql-hackers

From Ronan Dunklau
Subject Re: A potential memory leak on Merge Join when Sort node is not below Materialize node
Date
Msg-id 2254070.ElGaqSPkdT@aivenronan
Whole thread Raw
In response to Re: A potential memory leak on Merge Join when Sort node is not below Materialize node  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: A potential memory leak on Merge Join when Sort node is not below Materialize node
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: Avoid memory leaks during base backups
Next
From: Tom Lane
Date:
Subject: Re: A potential memory leak on Merge Join when Sort node is not below Materialize node