Re: [HACKERS] Remove secondary checkpoint - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Remove secondary checkpoint
Date
Msg-id 16799.1509372619@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Remove secondary checkpoint  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] Remove secondary checkpoint
List 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 by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: [HACKERS] CUBE seems a bit confused about ORDER BY
Next
From: Simon Riggs
Date:
Subject: Re: [HACKERS] Remove secondary checkpoint