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.
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
