| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Matheus Alcantara" <matheusssilv97(at)gmail(dot)com> |
| Cc: | adoros(at)starfishstorage(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org, rmt(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #19480: PL/Python SRF crashes (SIGSEGV) when function is replaced mid-iteration: use-after-free in PLy_funct |
| Date: | 2026-06-05 19:11:25 |
| Message-ID: | 3770958.1780686685@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
"Matheus Alcantara" <matheusssilv97(at)gmail(dot)com> writes:
> On Mon Jun 1, 2026 at 8:26 PM -03, Tom Lane wrote:
>> Actually ... if memory serves, SQL-language functions use ValuePerCall
>> mode, so there probably already is a solution to this embedded in
>> functions.c. Did you look at that?
> I dind't look at this before but this was exactly the right call. SQL
> functions handle this by maintaining a per-call-site cache struct
> (SQLFunctionCache) in fn_extra that holds both the pointer to the
> long-lived hash entry and the execution state. The use_count is
> incremented when we first obtain the function and decremented via a
> MemoryContextCallback when fn_mcxt is deleted.
> I've adapted the same approach for PL/Python.
I've not read this patch yet but your high-level description seems
on-target.
Assuming the patch withstands review, there are three ways we could
proceed:
1. Hold it for v20.
2. Sneak it into v19.
3. Treat it as a back-patchable fix and put it into v18 as well.
(Going further back than v18 seems unreasonable because funccache.c
doesn't exist before that, so we'd have to back-patch it too.)
I do not think that #3 is really a great idea, mainly because the
failure case doesn't seem very likely to be hit in production,
and the lack of previous reports about this very ancient bug
bears that out.
I do find some attraction in #2, mainly because it would get the fix
into the field a year earlier than #1. But considering we're past
beta1 it may be too late for #2 to be reasonable either.
Looping in the RMT to see what they think...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Matheus Alcantara | 2026-06-05 19:35:18 | Re: BUG #19480: PL/Python SRF crashes (SIGSEGV) when function is replaced mid-iteration: use-after-free in PLy_funct |
| Previous Message | Tom Lane | 2026-06-05 18:17:21 | Re: Hashed SAOP on composite type with non-hashable column errors at runtime |