Re: plperlu stored procedure seems to freeze for a minute

Поиск
Список
Период
Сортировка
От Peter J. Holzer
Тема Re: plperlu stored procedure seems to freeze for a minute
Дата
Msg-id 20151203143653.GA23305@hjp.at
обсуждение исходный текст
Ответ на Re: plperlu stored procedure seems to freeze for a minute  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Ответы Re: plperlu stored procedure seems to freeze for a minute  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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/

Вложения

В списке pgsql-general по дате отправления:

Предыдущее
От: Merlin Moncure
Дата:
Сообщение: Re: json indexing and data types
Следующее
От: Tom Lane
Дата:
Сообщение: Re: plperlu stored procedure seems to freeze for a minute