| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | "Shulgin, Oleksandr" <oleksandr(dot)shulgin(at)zalando(dot)de> |
| Cc: | Pavel Stěhule <pavel(dot)stehule(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Greg S <stark(at)mit(dot)edu>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: On-demand running query plans using auto_explain and signals |
| Date: | 2015-08-29 15:44:12 |
| Message-ID: | 20150829154412.GC31526@awork2.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2015-08-29 16:02:15 | Re: to_json(NULL) should to return JSON null instead NULL |
| Previous Message | Andres Freund | 2015-08-29 15:40:54 | Re: 9.4 broken on alpha |