Re: On-demand running query plans using auto_explain and signals - Mailing list pgsql-hackers

From Andres Freund
Subject Re: On-demand running query plans using auto_explain and signals
Date
Msg-id 20150829154412.GC31526@awork2.anarazel.de
Whole thread Raw
In response to On-demand running query plans using auto_explain and signals  ("Shulgin, Oleksandr" <oleksandr.shulgin@zalando.de>)
Responses Re: On-demand running query plans using auto_explain and signals  ("Shulgin, Oleksandr" <oleksandr.shulgin@zalando.de>)
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: 9.4 broken on alpha
Next
From: Pavel Stehule
Date:
Subject: Re: to_json(NULL) should to return JSON null instead NULL