On 2013-06-15 10:45:28 -0400, Tom Lane wrote: > I wrote: > > Richard Poole <rich...@2ndquadrant.com> writes: > >> This behaviour appears in 6ac7facdd3990baf47efc124e9d7229422a06452 as a > >> side-effect of speeding things up by getting rid of setitimer() calls; > >> it's not obvious what's a good way to fix it without losing the benefits > >> of that commit. > > > Ugh. It doesn't sound very practical to try to guarantee that every > > single kernel call in the backend is set up to recover from EINTR, > > even though ideally they should all be able to cope. > > 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. 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
