Re: Unintended restart after recovery error - Mailing list pgsql-hackers

From Antonin Houska
Subject Re: Unintended restart after recovery error
Date
Msg-id 14098.1415958503@localhost
Whole thread Raw
In response to Re: Unintended restart after recovery error  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
Fujii Masao <masao.fujii@gmail.com> wrote:
> On Thu, Nov 13, 2014 at 8:30 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> 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.

My distinction was "during recovery" vs "outside recovery", rather than
"startup process" vs "checkpointer". But I'm not sure it's easy enough to
recognize that checkpointer (maybe also bgwriter) no longer participates in
recovery.

> 442231d7f71764b8c628044e7ce2225f9aa43b6 introduced the latter rule
> for hot-standby case.

I didn't fully understand the purpose of this condition until I saw the commit
message. Thanks for pointing out.

> 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.

Yes, that's what I thought too. But I think the current StartupXLOG() does not
always (need to) determine the exact boundary between crash and archive
recovery. I'd need to think more if the end of crash recovery can be safely
identified during the replay and signaled to postmaster.

--
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 by date:

Previous
From: Simon Riggs
Date:
Subject: Re: using custom scan nodes to prototype parallel sequential scan
Next
From:
Date:
Subject: PostgreSQL doesn't stop propley when --slot option is specified with pg_receivexlog.