Re: Shutting down a warm standby database in 8.2beta3

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Shutting down a warm standby database in 8.2beta3
Дата
Msg-id 21368.1163801024@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Shutting down a warm standby database in 8.2beta3  (Stephen Harris <lists@spuddy.org>)
Ответы Re: Shutting down a warm standby database in 8.2beta3  (Stephen Harris <lists@spuddy.org>)
Список pgsql-general
Stephen Harris <lists@spuddy.org> writes:
> Doing a shutdown "immediate" isn't to clever because it actually leaves
> the recovery threads running

> LOG:  restored log file "00000001000000010000003E" from archive
> LOG:  received immediate shutdown request
> LOG:  restored log file "00000001000000010000003F" from archive

Hm, that should work --- AFAICS the startup process should abort on
SIGQUIT the same as any regular backend.

[ thinks... ]  Ah-hah, "man system(3)" tells the tale:

     system() ignores the SIGINT and SIGQUIT signals, and blocks the
     SIGCHLD signal, while waiting for the command to terminate.  If this
     might cause the application to miss a signal that would have killed
     it, the application should examine the return value from system() and
     take whatever action is appropriate to the application if the command
     terminated due to receipt of a signal.

So the SIGQUIT went to the recovery script command and was missed by the
startup process.  It looks to me like your script actually ignored the
signal, which you'll need to fix, but it also looks like we are not
checking for these cases in RestoreArchivedFile(), which we'd better fix.
As the code stands, if the recovery script is killed by a signal, we'd
take that as normal termination of the recovery and proceed to come up,
which is definitely the Wrong Thing.

            regards, tom lane

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

Предыдущее
От: Devrim GUNDUZ
Дата:
Сообщение: Re: PostgreSQL RPMs
Следующее
От: Tom Lane
Дата:
Сообщение: Re: can't delete because of constraint from zombie table