From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Remove secondary checkpoint |
Date: | 2017-10-30 14:10:19 |
Message-ID: | 16799.1509372619@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2017-10-30 14:22:31 | Re: Remove secondary checkpoint |
Previous Message | Alexander Korotkov | 2017-10-30 14:04:24 | Re: CUBE seems a bit confused about ORDER BY |