Message-ID: <c07f8261-4c65-47da-bb97-5a2246816b57@iki.fi>
Date: Wed, 17 Jun 2026 18:30:30 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: BUG #19480: PL/Python SRF crashes (SIGSEGV) when function is
 replaced mid-iteration: use-after-free in PLy_funct
To: Matheus Alcantara <matheusssilv97@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: adoros@starfishstorage.com, pgsql-bugs@lists.postgresql.org,
 rmt@lists.postgresql.org
References: <19480-f1f9fdce30462fc4@postgresql.org>
 <DIS405H05GE0.1OPMN9BEKKMS1@gmail.com> <982975.1779981146@sss.pgh.pa.us>
 <DIY2500FL0UW.Z4M7NYWMGGA4@gmail.com> <2868592.1780356411@sss.pgh.pa.us>
 <DJ1BFHKUC06G.1NO3D0WC9KBV6@gmail.com> <3770958.1780686685@sss.pgh.pa.us>
 <9ecd2bd5-0fec-4ec2-9800-eb071683128c@gmail.com>
Content-Language: en-US
From: Heikki Linnakangas <hlinnaka@iki.fi>
In-Reply-To: <9ecd2bd5-0fec-4ec2-9800-eb071683128c@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/c07f8261-4c65-47da-bb97-5a2246816b57%40iki.fi>
Precedence: bulk

On 05/06/2026 22:35, Matheus Alcantara wrote:
> On 05/06/26 16:11, Tom Lane wrote:
>> "Matheus Alcantara" <matheusssilv97@gmail.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.
>>
> 
> Yeah, this sounds a better option for me too, otherwise we can go with 
> #1. Back-patching this seems complicated, so I agree #3 does not seems a 
> good idea.
> 
>> Looping in the RMT to see what they think...

It's fine to still sneak it into v19. It's better to have it earlier, 
even if it means more churn during beta period.

I haven't looked closely at the patch, but since it's a bug fix it would 
make sense to backpatch. If we're uncomfortable with backpatching it 
now, we could commit in master now, and backpatch later when we have 
more confidence.

- Heikki