agora inbox for pgsql-hackers@postgresql.org  
help / color / mirror / Atom feed
From: 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