Re: [PATCH] plpython function causes server panic

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Hao Zhang <zhrt1446384557(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [PATCH] plpython function causes server panic
Date: 2023-12-02 01:46:26
Message-ID: 306924.1701481586@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2023-12-01 20:04:15 -0500, Tom Lane wrote:
>> Thanks for the report! I see the problem is that we're not expecting
>> BeginInternalSubTransaction to fail. However, I'm not sure I like
>> this solution, mainly because it's only covering a fraction of the
>> problem. There are similarly unsafe usages in plperl, pltcl, and
>> very possibly a lot of third-party PLs. I wonder if there's a way
>> to deal with this issue without changing these API assumptions.

> There are plenty other uses, but it's not clear to me that they are similarly
> affected by BeginInternalSubTransaction raising an error? It e.g. doesn't
> immediately look like plperl's usage would be affected in a similar way?

Why not? We'd be longjmp'ing out from inside the Perl interpreter.
Maybe Perl is so robust it doesn't care, but I'd be surprised if this
can't break it. The same for Tcl.

I think that plpgsql indeed doesn't care because it has no non-PG
interpreter state to worry about. But it's in the minority I fear.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2023-12-02 01:51:11 Re: [PATCH] plpython function causes server panic
Previous Message Andres Freund 2023-12-02 01:30:07 Re: [PATCH] plpython function causes server panic