| From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
|---|---|
| To: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Remove secondary checkpoint |
| Date: | 2017-10-25 01:33:51 |
| Message-ID: | CAB7nPqSMvoWecgjSkcFXXbNbrVuFDkBo08SRMKP2tvWEuACHcA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Oct 24, 2017 at 5:58 PM, Tsunakawa, Takayuki
<tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> wrote:
> If the latest checkpoint record is unreadable (the WAL segment/block/record is corrupt?), recovery from the previous checkpoint would also stop at the latest checkpoint. And we don't need to replay the WAL records between the previous checkpoint and the latest one, because their changes are already persisted when the latest checkpoint was taken. So, the user should just do pg_resetxlog and start the database server when the recovery cannot find the latest checkpoint record and PANICs?
Not necessarily. If a failure is detected when reading the last
checkpoint, as you say recovery would begin at the checkpoint prior
that and would stop when reading the record of last checkpoint, still
one could use a recovery.conf with restore_command to fetch segments
from a different source, like a static archive, as only the local
segment may be corrupted.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tsunakawa, Takayuki | 2017-10-25 01:48:43 | Re: Remove secondary checkpoint |
| Previous Message | Tsunakawa, Takayuki | 2017-10-25 00:58:15 | Re: Remove secondary checkpoint |