Fujii Masao <masao.fu...@gmail.com> wrote: > On Wed, Nov 12, 2014 at 6:52 PM, Antonin Houska <a...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
