Re: A potential memory leak on Merge Join when Sort node is not below Materialize node
От | Peter Geoghegan |
---|---|
Тема | Re: A potential memory leak on Merge Join when Sort node is not below Materialize node |
Дата | |
Msg-id | CAH2-Wzk7yu++f=3Dj=2nnLQMBvOiCTnrjO9BTQno4uRrDY4C4w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: A potential memory leak on Merge Join when Sort node is not below Materialize node (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: A potential memory leak on Merge Join when Sort node is not below Materialize node
|
Список | pgsql-hackers |
On Wed, Sep 28, 2022 at 12:57 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > 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. I am reminded of the discussion that led to bugfix commit c2d4eb1b some years back. As the commit message of that old bugfix notes, tuplesort_getdatum() and tuplesort_gettupleslot() are "the odd ones out" among "get tuple" routines (i.e. routines that get a tuple from a tuplesort by calling tuplesort_gettuple_common()). We used to sometimes do that with tuplesort_getindextuple() and possible other such routines, but the need for that capability was eliminated on the caller side around the same time as the bugfix went in. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: