Re: Why has postmaster shutdown gotten so slow?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Why has postmaster shutdown gotten so slow?
Дата
Msg-id 11927.1076099475@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Why has postmaster shutdown gotten so slow?  (Jan Wieck <JanWieck@Yahoo.com>)
Ответы Re: Why has postmaster shutdown gotten so slow?  (Jan Wieck <JanWieck@Yahoo.com>)
Список pgsql-hackers
Jan Wieck <JanWieck@Yahoo.com> writes:
> I checked the background writer for this and I can not reproduce the 
> behaviour. If the bgwriter had zero blocks to write it does PG_USLEEP 
> for 10 seconds, which on Unix is done by select() and that is correctly 
> interrupted when the postmaster sends it the term signal on shutdown.

This appears to be a platform-dependent behavior.  The HPUX select(2) man
page says
         [EINTR]        The select() function was interrupted before any                        of the selected events
occurredand before the                        timeout interval expired. If SA_RESTART has been
setfor the interrupting signal, it is                        implementation-dependent whether select() restarts
              or returns with EINTR.
 

which text also appears verbatim in the Single Unix Spec.  Since we set
SA_RESTART for every signal except SIGALRM (see pqsignal.c), we are
subject to the implementation dependency for SIGTERM.

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.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Meskes
Дата:
Сообщение: Recursive queries patch
Следующее
От: markw@osdl.org
Дата:
Сообщение: Re: Proposed Query Planner TODO items