Re: BUG #19480: PL/Python SRF crashes (SIGSEGV) when function is replaced mid-iteration: use-after-free in PLy_funct

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
Subject: Re: BUG #19480: PL/Python SRF crashes (SIGSEGV) when function is replaced mid-iteration: use-after-free in PLy_funct
Date: 2026-06-21 19:40:04
Message-ID: 381335.1782070804@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:
> Thanks for the review! I've tried to address all your points in the
> attached v2.

Pushed after a round of review. I made some mostly-cosmetic changes,
such as rewriting comments (consolidating some stuff I thought was
duplicative). The main thing I fixed that was an actual bug was
you were careless about lifespan of variables around PG_TRY blocks.
The rule of thumb is that if a variable is modified inside PG_TRY
and then used after that block (including in the PG_CATCH) then it
has to be marked volatile. Where possible, I avoid using the
volatile marking by assigning the variable's value before PG_TRY.

> I've also added a regression test, not sure if there is a better way to
> exercise this fix but this test crash without this patch applied.

Kind of a hokey test, since it doesn't model the likely actual case
where the CREATE happens in another session, but this is as close as
we'll get without a much more complex test setup. I kept it, and
also added another test that exercises the early-termination path,
since code coverage showed me that ShutdownPLyFunction() wasn't being
reached.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Previous Message carl clemens 2026-06-21 19:27:20 Re: psql variable substitution in plpgsql loop