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

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: On-demand running query plans using auto_explain and signals
Дата
Msg-id 20150829154412.GC31526@awork2.anarazel.de
обсуждение исходный текст
Ответ на On-demand running query plans using auto_explain and signals  ("Shulgin, Oleksandr" <oleksandr.shulgin@zalando.de>)
Ответы Re: On-demand running query plans using auto_explain and signals
Список pgsql-hackers
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

Andres



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: 9.4 broken on alpha
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: to_json(NULL) should to return JSON null instead NULL