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

2015-08-29 18:25 GMT+02:00 Shulgin, Oleksandr <oleksandr(dot)shulgin(at)zalando(dot)de>
:

> On Sat, Aug 29, 2015 at 5:44 PM, Andres Freund <andres(at)anarazel(dot)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.
>

I had a workable prototype - and It was implemented very similar as
handling CANCEL

Pavel