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 20151203143653.GA23305@hjp.at
Whole thread Raw
In response to Re: plperlu stored procedure seems to freeze for a minute  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: plperlu stored procedure seems to freeze for a minute  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On 2015-12-02 19:07:55 -0600, Jim Nasby wrote:
> On 12/2/15 9:26 AM, Peter J. Holzer wrote:
> >As explained in backend/utils/misc/timeout.c, the timers are never
> >cancelled: If a timeout is cancelled, postgres just sees that it has
> >nothing to do and resumes whatever it is doing.
>
> Hrm, if those timers are really just for auth purposes then perhaps they
> should be cancelled. But aside from that, there's certainly other things
> that can signal a backend (including fairly normal things, like DDL).

Yep. I noticed that, too. In one of my test runs I got two signals
instead of the one I expected. Checking the logs I found that it seemed be
caused by another user dropping a table.

> Offhand I don't think functions run in a CRITICAL block (and I don't think
> it'd be a good idea for them to). So really, functions have to be handle
> being interrupted.

Right. I think that should be mentioned somewhere in the manual.
Something like this:

    Note: PostgreSQL uses signals for various purposes. These signals
    may be delivered while a user-defined function is executed.
    Therefore user-defined functions must be able to handle being
    interrupted, in particular they must expect system calls to fail
    with errno=EINTR and handle that case appropriately.

I'm not sure wether that's an issue with all procedural languages. If it
is, it should probable go into "Chapter 39. Procedural Languages". If it
is specific to plperl(u), I would put it in "42.8.2. Limitations and
Missing Features".

> Yeah, it'd be nice to detect that this had happened. Or maybe it's worth it
> to ignore SIGALARM while a UDF is running.

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.

    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: Merlin Moncure
Date:
Subject: Re: json indexing and data types
Next
From: Tom Lane
Date:
Subject: Re: plperlu stored procedure seems to freeze for a minute