Re: Missing pg_control crashes postmaster

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Missing pg_control crashes postmaster
Дата
Msg-id 20180725152614.y4fhrlrjqwjxiv4t@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Missing pg_control crashes postmaster  (David Steele <david@pgmasters.net>)
Ответы Re: Missing pg_control crashes postmaster  (David Steele <david@pgmasters.net>)
Список pgsql-hackers
Hi,

On 2018-07-25 11:19:49 -0400, David Steele wrote:
> On 7/25/18 11:09 AM, Andres Freund wrote:
> > On 2018-07-25 10:52:08 -0400, David Steele wrote:
> > The problem is that that'll just hide the issue for a bit longer, while
> > continuing (due to the O_CREAT we'll not PANIC anymore).  Which can lead
> > to a lot of followup issues, like checkpoints removing old WAL that'd
> > have been useful for data recovery.
> 
> So if a panic is the best thing to do, it might still be good to write out a
> copy of pg_control to another file and let the user know that it's there.
> More information seems better than less to me.

Sure, if that were the only concern. But code complexity and testability
also is. This means we need to maintain code for an edge case that
nobody has come up with a reason for. And at least during development,
we need to come up with test cases. Or we continually run the test case
as part of the regression tests for something without any sort of
practical relevance.

If one wanted to improve recoverability in scenarios like this, there'd
be actually useful things like adding the option to extract control
files, FPIs, clog contents from the WAL with pg_waldump.

Greetings,

Andres Freund


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Nico Williams
Дата:
Сообщение: Re: How can we submit code patches that implement our (pending)patents?
Следующее
От: Nico Williams
Дата:
Сообщение: Re: Early WIP/PoC for inlining CTEs