Re: Unintended restart after recovery error
От | Fujii Masao |
---|---|
Тема | Re: Unintended restart after recovery error |
Дата | |
Msg-id | CAHGQGwHixg9SPS9qqbVQCeWQG=zY5Y0MzBa57KuNb_8aL=Mvuw@mail.gmail.com обсуждение исходный текст |
Ответ на | Unintended restart after recovery error (Antonin Houska <ah@cybertec.at>) |
Ответы |
Re: Unintended restart after recovery error
|
Список | pgsql-hackers |
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? Regards, -- Fujii Masao
В списке pgsql-hackers по дате отправления: