| 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
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Japin Li | 2026-07-07 01:09:44 | Re: Global temporary tables |