agora inbox for pgsql-hackers@postgresql.org
help / color / mirror / Atom feedFrom: Andrey Rachitskiy <pl0h0yp1@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Cc: Nikolay Shaplov <dhyan@nataraj.su>
Subject: Re: [PATCH] Limit PL/Perl scalar copies to work_mem
Date: Tue, 7 Jul 2026 10:44:45 +0500
Message-ID: <20260707104445.4e0816b1@pg-ThinkPad-T14-Gen-4> (raw)
In-Reply-To: <1792143.1783389377@sss.pgh.pa.us>
References: <20260707034157.5e88bf34@pg-ThinkPad-T14-Gen-4>
<1792143.1783389377@sss.pgh.pa.us>
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@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.
>
> 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
view thread (4+ messages)
Message-ID: <20260707104445.4e0816b1@pg-ThinkPad-T14-Gen-4>
Permalink: ../20260707104445.4e0816b1@pg-ThinkPad-T14-Gen-4/
Also on: postgresql.org/message-id/20260707104445.4e0816b1@pg-ThinkPad-T14-Gen-4
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: pl0h0yp1@gmail.com, tgl@sss.pgh.pa.us, pgsql-hackers@lists.postgresql.org, dhyan@nataraj.su
Subject: Re: [PATCH] Limit PL/Perl scalar copies to work_mem
In-Reply-To: <20260707104445.4e0816b1@pg-ThinkPad-T14-Gen-4>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox