Re: A potential memory leak on Merge Join when Sort node is not below Materialize node
От | Tom Lane |
---|---|
Тема | Re: A potential memory leak on Merge Join when Sort node is not below Materialize node |
Дата | |
Msg-id | 4032218.1664395030@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | 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
Re: A potential memory leak on Merge Join when Sort node is not below Materialize node |
Список | pgsql-hackers |
David Rowley <dgrowleyml@gmail.com> writes: > I'm wondering if the best way to fix it if doing it that way would be > to invent tuplesort_getdatum_nocopy() which would be the same as > tuplesort_getdatum() except it wouldn't do the datumCopy for byref > types. Yeah, perhaps. We'd need a clear spec on how long the Datum could be presumed good --- probably till the next tuplesort_getdatum_nocopy call, but that'd need to be checked --- and then check if that is satisfactory for nodeSort's purposes. If we had such a thing, I wonder if any of the other existing tuplesort_getdatum callers would be happier with that. nodeAgg for one is tediously freeing the result, but could we drop that logic? (I hasten to add that I'm not proposing we touch that for v15.) regards, tom lane
В списке pgsql-hackers по дате отправления: