Date: Tue, 7 Jul 2026 10:44:45 +0500
From: Andrey Rachitskiy <pl0h0yp1@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Nikolay Shaplov
 <dhyan@nataraj.su>
Subject: Re: [PATCH] Limit PL/Perl scalar copies to work_mem
Message-ID: <20260707104445.4e0816b1@pg-ThinkPad-T14-Gen-4>
In-Reply-To: <1792143.1783389377@sss.pgh.pa.us>
References: <20260707034157.5e88bf34@pg-ThinkPad-T14-Gen-4>
	<1792143.1783389377@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/20260707104445.4e0816b1%40pg-ThinkPad-T14-Gen-4>
Precedence: bulk

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 =E2=80=94 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@sss.pgh.pa.us> wrote:

> 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.
>=20
> 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.
>=20
> > This patch rejects Perl strings larger than work_mem * 1024 bytes,
>=20
> 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.
>=20
> So, even if I thought this were something we should address,
> I don't believe this is an appropriate approach to a fix.
>=20
> 			regards, tom lane


--=20
Regards,
Andrey Rachitskiy