| From: | Mario Karuza <mkaruza(dot)pg(at)icloud(dot)com> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(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-10-05 06:59:20 |
| Message-ID: | 9b196fa8-c32e-4516-a939-1e4aeeb12e6d@icloud.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 05.10.2026. 08:06, David Rowley wrote:
> 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.
>
> Can you share how you found this issue? e.g., was it a problem you
> found in production because of excessive memory usage? or was it
> human, AI, or other tooling looking at the code?
>
> David
Sure, there was no production issue, it was driven by exploration if AIO
subsystem and if it can be used around spilling. Noticed `still in
progress` from EXPLAIN ANALYZE output, used AI agent to understand
execution path and there was fixed argument that was passed to function.
Commit 6ed83d5fa55 covered other paths but not this one.
--
Regards,
Mario Karuza
| From | Date | Subject | |
|---|---|---|---|
| Next Message | vignesh C | 2026-10-05 07:01:59 | Re: Publication DDL can race with a concurrent UPDATE |
| Previous Message | solai v | 2026-10-05 06:57:40 | Re: Preserve statistics targets with ALTER TABLE ALTER COLUMN TYPE |