| 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
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | carl clemens | 2026-06-21 19:27:20 | Re: psql variable substitution in plpgsql loop |