On Thu, Nov 13, 2014 at 8:30 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Nov 12, 2014 at 4:52 PM, Antonin Houska <a...@cybertec.at> wrote: >> 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. > > It's true that if the startup process dies we don't try to restart, > but it's also true that if the checkpointer dies we do try to restart. > I'm not sure why this specific situation should be an exception to > that general rule.
442231d7f71764b8c628044e7ce2225f9aa43b6 introduced the latter rule for hot-standby case. Maybe *during crash recovery* (i.e., hot standby should not be enabled) it's better to treat the crash of startup process as a catastrophic crash. Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
