Thanks for the review, Tom. You're right that work_mem is a poor fit for a hard failure here, and more generally that this isn't the sort of problem PL/Perl can solve with a small boundary check alone. I should have raised the idea on the list for discussion before sending a patch — I'll do that next time rather than charging ahead with a fix.
Thanks for the feedback. On Mon, 06 Jul 2026 21:56:17 -0400, Tom Lane <[email protected]> wrote: > Andrey Rachitskiy <[email protected]> writes: > > When a PL/Perl function returns a large text value, sv2cstr() > > copies the entire Perl string into backend memory with no size > > check. The helper is used on the path from Perl return values and > > SPI arguments to PostgreSQL text datums; it simply palloc()s a copy > > after SvPVutf8(). A user who is allowed to create untrusted PL/Perl > > functions can therefore force the backend to allocate strings far > > larger than any session limit. On a memory-constrained host this > > can get the backend process killed by the OOM killer (SIGKILL) > > rather than raising a catchable PostgreSQL error. > > This is true of very many operations in PG, not only PL/Perl. > Our general answer to that is to disable memory overcommit > so that the OOM killer won't apply. One should also note that > the same PL/Perl function can (try to) allocate enormous amounts > of memory entirely within Perl, where we have no ability to stop > it. I don't see how constraining the size of a function result > string helps noticeably. > > > This patch rejects Perl strings larger than work_mem * 1024 bytes, > > Our normal understanding of work_mem is that it's a point beyond which > we'll spill to disk, or otherwise try to reduce our memory consumption > at the cost of longer runtime. Not a point at which an outright query > failure is OK. > > So, even if I thought this were something we should address, > I don't believe this is an appropriate approach to a fix. > > regards, tom lane -- Regards, Andrey Rachitskiy
