| From: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
|---|---|
| To: | 'Tom Lane' <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Remove secondary checkpoint |
| Date: | 2017-10-25 00:58:15 |
| Message-ID: | 0A3221C70F24FB45833433255569204D1F80B8E1@G01JPEXMBYT05 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
From: pgsql-hackers-owner(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of Tom Lane
> Doesn't it also make crash recovery less robust? The whole point
> of that mechanism is to be able to cope if the latest checkpoint
> record is unreadable.
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?
Regards
Takayuki Tsunakawa
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2017-10-25 01:33:51 | Re: Remove secondary checkpoint |
| Previous Message | Michael Paquier | 2017-10-25 00:37:18 | Implementing pg_receivewal --no-sync |