| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | Mario Karuza <mkaruza(dot)pg(at)icloud(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: tuplesort_putdatum() does not account for tuple memory |
| Date: | 2026-09-11 00:05:02 |
| Message-ID: | CAApHDvqL95PWsyxJRYt1tkDLxF035691bYW5Oe6975Wx_0cYxw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 11 Sept 2026 at 08:36, Mario Karuza <mkaruza(dot)pg(at)icloud(dot)com> wrote:
> Memory allocated for copied pass-by-reference Datums was not accounted
> against work_mem because tuplesort_putdatum() passed a hardcoded tuplen
> of 0 to tuplesort_puttuple_common(). Function free_sort_tuple() adjusts
> the accounting by the amount actually allocated, so freeing such a
> tuple subtracts an amount that was never added.
>
> This was introduced in 6ed83d5fa55, which switched non-bounded sorts to
> bump contexts. That commit correctly changed the other tuplesort_put*()
> functions to compute the size, leaving only this one passing hardcoded
> 0.
I wondered if the extra strlen() call in datumGetSize() would result
in a slowdown, but looking deeper, it seems like that won't be hit due
to lack of sort support for cstring types.
I don't see any issues with the patch. I will process it on Monday, to
give time in case other people want to look.
David
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Andrew Dunstan | 2026-09-10 23:59:08 | Re: pg_get_*_ddl() needs a redesign |