Re: plperlu stored procedure seems to freeze for a minute - Mailing list pgsql-general

From Peter J. Holzer
Subject Re: plperlu stored procedure seems to freeze for a minute
Date
Msg-id 20151204101534.GA2214@hjp.at
Whole thread Raw
In response to Re: plperlu stored procedure seems to freeze for a minute  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: plperlu stored procedure seems to freeze for a minute  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-general
On 2015-12-03 10:02:18 -0500, Tom Lane wrote:
> "Peter J. Holzer" <hjp-pgsql@hjp.at> writes:
> > Can those signals be safely ignored? Just blocking them (so that they
> > are delivered after the UDF finishes) might be safer. But even that may
> > be a problem: If the UDF then executes some SQL, could that rely on
> > signals being delivered? I have no idea.
>
> The minute you start fooling with a backend's signal behavior, we're
> going to politely refuse to support whatever breakage you run into.

As I understood Jim he was talking about possible changes to postgresql
to shield UDFs from those signals, not something the author of a UDF
should do.


> We aren't sending those signals just for amusement's sake.

Right. That's why I was sceptical whether those signals could be
ignored. I wouldn't have thought so, but Jim clearly knows a lot more
about the inner workings of postgresql than I do (which is easy - I know
almost nothing) and maybe he knows of a way (something like "we can
ignore signals while executing the UDF and just assume that we missed at
least one signal and call the magic synchronize state function
afterwards")

    hp

--
   _  | Peter J. Holzer    | I want to forget all about both belts and
|_|_) |                    | suspenders; instead, I want to buy pants
| |   | hjp@hjp.at         | that actually fit.
__/   | http://www.hjp.at/ |   -- http://noncombatant.org/

Attachment

pgsql-general by date:

Previous
From: Tim Smith
Date:
Subject: JDBC and inet type
Next
From: rob stone
Date:
Subject: Re: JDBC and inet type