On Tue, May 23, 2017 at 9:45 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> Just out of curiosity, what happens if you try it with the attached patch? > > Surely that's pretty unsafe?
Yes. I was just curious to see whether it would work. I think what we need to do is teach pqsignal() to block all of the necessary signals using sa_mask and then remove all of the explicit blocking/unblocking logic from the signal handlers themselves. IIUC, the point of sa_mask is precisely that you want the operating system to handle the save/restore of the signal mask rather than doing it yourself in the handler, precisely because doing it in the handler creates windows at the beginning and end of the handler where the mask may not be what you want. In the case of Linux and MacOS, at least, the default behavior (unless SA_NODEFER is set) is to automatically block the signal currently being handled, so there's likely no way to blow out the stack during the brief window before PG_SETMASK(&BlockSig) is called. You could receive some *other* signal during that window, but then that one would blocked too, so I don't think you can stack up more frames this way than the number of distinct signal handlers you have. However, the window at the end of the function - after PG_SETMASK(&UnBlockSig) has been invoked - can recurse arbitrarily deep. At that point we've unblocked the signal we're currently handling, so we're playing with fire. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
