Re: On-demand running query plans using auto_explain and signals

Поиск
Список
Период
Сортировка
От Shulgin, Oleksandr
Тема Re: On-demand running query plans using auto_explain and signals
Дата
Msg-id CACACo5TiL7xZ4+oMTBPKRCKt9AoX4Ui+RJfW3ozDZZy+DdsKog@mail.gmail.com
обсуждение исходный текст
Ответ на Re: On-demand running query plans using auto_explain and signals  (Andres Freund <andres@anarazel.de>)
Ответы Re: On-demand running query plans using auto_explain and signals  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
On Sat, Aug 29, 2015 at 5:44 PM, Andres Freund <andres@anarazel.de> wrote:
On 2015-08-29 17:33:22 +0200, Shulgin, Oleksandr wrote:
> Probably using SIGUSR2 would be more appropriate, but I'm not sure if there
> are other extensions out there that might be already using it for some
> other reason (well, I do not know that for SIGUSR1 either).  Looking at the
> current state of affairs in procsignal_sigusr1_handler() makes me believe
> it should be pretty safe to catch the signal like I do.  Or is that not the
> case?

You can catch signals, but you're not allowed to do a lot from
them. Anything allocating memory, acquiring locks, etc. is out - these
functions aren't reentrant.  If you can guarantee that you're not
interrupting any relevant code you can bend those rules, but that's
obviously not the case here.

Check out the list of async-signal-safe functions at http://man7.org/linux/man-pages/man7/signal.7.html

Good point.  There's still hope to set a flag and process it later on.  Will have to check if it's possible to stay in the scope of a loaded module though.

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

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: to_json(NULL) should to return JSON null instead NULL
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: On-demand running query plans using auto_explain and signals