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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrey Rachitskiy <pl0h0yp1(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Nikolay Shaplov <dhyan(at)nataraj(dot)su>
Subject: Re: [PATCH] Limit PL/Perl scalar copies to work_mem
Date: 2026-07-07 01:56:17
Message-ID: 1792143.1783389377@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Previous Message Japin Li 2026-07-07 01:09:44 Re: Global temporary tables