I wrote: > ... Also, our switch to latches for sleeping purposes > should have ameliorated the issue of signals failing to wake processes > when we wanted them to.
> Let's turn on SA_RESTART for SIGALRM in HEAD and 9.3 and see what beta > testing says. I experimented with this a bit on my old HPUX box (which is one of the ones where SA_RESTART signals don't terminate a select()), and soon found an annoying behavior: regression=# \timing Timing is on. regression=# set statement_timeout TO 2000; SET Time: 4.983 ms regression=# select generate_series(1,1000000); ERROR: canceling statement due to statement timeout Time: 2015.015 ms regression=# select pg_sleep(10); ERROR: canceling statement due to statement timeout Time: 3009.932 ms This happens because pg_sleep() is implemented with a loop around pg_usleep(1000000), and the latter no longer is terminated by a SIGALRM. It seems like it'd be a good idea to replace the pg_sleep implementation with something involving WaitLatch, which would not only ensure prompt response to SIGALRM (and other signals, eg SIGQUIT), but would eliminate useless process wakeups during a sleep. In general, we might want to consider replacing long sleep intervals with WaitLatch operations. I thought for a bit about trying to turn pg_usleep itself into a WaitLatch call; but it's also used in frontend code where that wouldn't work, and anyway it's not clear this would be a good thing for short sleeps. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers