Re: [HACKERS] Remove secondary checkpoint

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Remove secondary checkpoint
Дата
Msg-id 16799.1509372619@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Remove secondary checkpoint  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] Remove secondary checkpoint  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> I was mostly just thinking out loud, listing another option rather
> than advocating for it.

FWIW, I just wanted the question to be debated and resolved properly.

After rereading the thread Andres pointed to, I thought of a hazard
that I think Andres alluded to, but didn't spell out explicitly:
if we can't read the primary checkpoint, and then back up to a
secondary one and replay as much of WAL as we can read, we may well
be left with an inconsistent database.  This would happen because
some changes that post-date the part of WAL we could read may have
been flushed to disk, if the system previously thought that WAL
up through the primary checkpoint was all safely down to disk.
Therefore, backing up to the secondary checkpoint is *not* a safe
automatic recovery choice, and it's dubious that it's even a useful
approach for manual recovery.  You're really into restore-from-
backup territory at that point.

I'm content now that removing the secondary checkpoint is an OK
decision.  (This isn't a review of Simon's patch, though.)
        regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

Предыдущее
От: Alexander Korotkov
Дата:
Сообщение: Re: [HACKERS] CUBE seems a bit confused about ORDER BY
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: [HACKERS] Remove secondary checkpoint