On 05.10.2026. 08:06, David Rowley wrote: > On Fri, 11 Sept 2026 at 08:36, Mario Karuza <[email protected]> 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
