| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io>, Önder Kalacı <onderkalaci(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: A potential memory leak on Merge Join when Sort node is not below Materialize node |
| Date: | 2022-09-28 19:57:10 |
| Message-ID: | 4032218.1664395030@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
David Rowley <dgrowleyml(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2022-09-28 20:07:13 | Re: longfin and tamandua aren't too happy but I'm not sure why |
| Previous Message | Peter Geoghegan | 2022-09-28 19:49:36 | Re: longfin and tamandua aren't too happy but I'm not sure why |