Re: Unintended restart after recovery error

Поиск
Список
Период
Сортировка
От Antonin Houska
Тема Re: Unintended restart after recovery error
Дата
Msg-id 14098.1415958503@localhost
обсуждение исходный текст
Ответ на Re: Unintended restart after recovery error  (Fujii Masao <masao.fujii@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: using custom scan nodes to prototype parallel sequential scan
Следующее
От:
Дата:
Сообщение: PostgreSQL doesn't stop propley when --slot option is specified with pg_receivexlog.