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

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrey Rachitskiy <pl0h0yp1@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Nikolay Shaplov <dhyan@nataraj.su>
Date: 2026-07-07T01:56:17Z
Lists: pgsql-hackers
Andrey Rachitskiy <pl0h0yp1@gmail.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