>> Tracing the bgwriter process on my machine makes it real 
>obvious that in
>> fact the select delay is allowed to finish out when SIGTERM 
>is received.
>> In fact worse than that: it's restarted from the beginning.  If 5
>> seconds have already elapsed, another 10 still elapse before 
>the select
>> exits.
>> 
>> This won't do :-(.  We cannot afford to fritter away 10 
>seconds in the
>> SIGTERM shutdown cycle --- on typical systems init isn't 
>going to give
>> us more than 20 seconds before a hard kill.
>> 
>> I'd suggest reducing the delay to a second or two, or 
>perhaps breaking
>> it into several 1-second waits with interrupt flag checks between.
>> 
>> In the longer run we might want to rethink what we are doing with
>> SA_RESTART, but I am not sure about the implications of fooling with
>> that.
>
>I think we should at this point have some maximum value for PG_xSLEEP 
>over which it falls back to a function call that does either this 
>breaking up into a loop with checking InterruptPending or removes the 
>SA_RESTART flag while wating for the timeout.

If you look at my win32 signals patch nr 3 (posted feb 4th), I have code
to do this for win32 in it. It breaks up select() timeouts into pieces
of 1 second and polls for win32 signals inbetween. 

Turns out it wasn't necessary, since win32 *does* deliver our signals
whlie in select. So for once it's win32 that does what we want - I think
that's a first.. But it might help on another platform.


//Magnus

Sat, 7 Feb 2004 01:21:09 +0100
"Magnus Hagander" <mha@sollentuna.net>
Re: Why has postmaster shutdown gotten so slow?