Message-ID: <9ecd2bd5-0fec-4ec2-9800-eb071683128c@gmail.com>
Date: Fri, 5 Jun 2026 16:35:18 -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: 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>
Content-Language: en-US
From: Matheus Alcantara <matheusssilv97@gmail.com>
In-Reply-To: <3770958.1780686685@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/9ecd2bd5-0fec-4ec2-9800-eb071683128c%40gmail.com>
Precedence: bulk

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...
> 

Ok

--
Matheus Alcantara
EDB: https://www.enterprisedb.com