On 2013-06-15 11:29:45 -0400, Tom Lane wrote: > Andres Freund <and...@2ndquadrant.com> writes: > > On 2013-06-15 10:45:28 -0400, Tom Lane wrote: > >> On reflection though, we *do* need to make them cope, because even > >> without lazy SIGALRM disable, any such place is still at risk. We > >> surely must allow for the possibility of SIGHUP arriving at any instant, > >> for example. > > > All signal handlers we register, including SIGHUP, but the one for > > SIGALRM set SA_RESTART... I wonder if we can rejigger things so we don't > > need that? I am not sure if there's still a reason for that decision > > inside the backend. > > Hmm. Personally I'd rather go in the other direction: > http://www.postgresql.org/message-id/12819.1183306...@sss.pgh.pa.us > but maybe the path of least resistance is to set SA_RESTART for SIGALRM > too. Given our current usage of it, there seems no worse harm in > allowing kernel calls to restart after a SIGALRM than any other signal.
I am not actually objecting that reasoning, I think it would be rather useful to get there. But I don't think it's realistic to do that at this point in the 9.3 cycle. It seems like we would fight bugs around that for quite a while. We have a large number of syscall sites where we don't retry on EINTR/EAGAIN. And, as you note, that's not even talking about third party code. I'd be happy if we decide to go that way at the beginning of the 9.4 cycle. I.e. do it right now on HEAD for all syscalls. That way we have a chance to find most of the bad callsites before releasing. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
