Re: Unintended restart after recovery error
От | Antonin Houska |
---|---|
Тема | Re: Unintended restart after recovery error |
Дата | |
Msg-id | 30059.1415829176@localhost обсуждение исходный текст |
Ответ на | Re: Unintended restart after recovery error (Fujii Masao <masao.fujii@gmail.com>) |
Ответы |
Re: Unintended restart after recovery error
|
Список | pgsql-hackers |
Fujii Masao <masao.fujii@gmail.com> wrote: > On Wed, Nov 12, 2014 at 6:52 PM, Antonin Houska <ah@cybertec.at> wrote: > > While looking at postmaster.c:reaper(), one problematic case occurred to me. > > > > > > 1. Startup process signals PMSIGNAL_RECOVERY_STARTED. > > > > 2. Checkpointer process is forked and immediately dies. > > > > 3. reaper() catches this failure, calls HandleChildCrash() and thus sets > > FatalError to true. > > > > 4. Startup process exits with non-zero status code too - either due to SIGQUIT > > received from HandleChildCrash or due to some other failure of the startup > > process itself. However, FatalError is already set, because of the previous > > crash of the checkpointer. Thus reaper() does not set RecoveryError. > > > > 5. As RecoverError failed to be set to true, postmaster will try to restart > > the cluster, although it apparently should not. > > Why shouldn't postmaster restart the cluster in that case? > At least for the behavior to be consistent with simpler cases of failed recovery (e.g. any FATAL error in StartupXLOG), which end up not restarting the cluster. -- Antonin Houska Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de, http://www.cybertec.at
В списке pgsql-hackers по дате отправления: