Re: [PATCH] Limit PL/Perl scalar copies to work_mem

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 <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Andrey Rachitskiy <pl0h0yp1(at)gmail(dot)com> 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