Re: stray SIGALRM - Mailing list pgsql-hackers

From Tom Lane
Subject Re: stray SIGALRM
Date
Msg-id 26820.1371323409@sss.pgh.pa.us
Whole thread Raw
In response to Re: stray SIGALRM  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: stray SIGALRM  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Batch API for After Triggers
Next
From: Gaetano Mendola
Date:
Subject: C++ compiler