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