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

From Tsunakawa, Takayuki
Subject Re: [HACKERS] Remove secondary checkpoint
Date
Msg-id 0A3221C70F24FB45833433255569204D1F80B8E1@G01JPEXMBYT05
Whole thread Raw
In response to Re: [HACKERS] Remove secondary checkpoint  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Remove secondary checkpoint
List pgsql-hackers
From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.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
checkpointwould also stop at the latest checkpoint.  And we don't need to replay the WAL records between the previous
checkpointand the latest one, because their changes are already persisted when the latest checkpoint was taken.  So,
theuser should just do pg_resetxlog and start the database server when the recovery cannot find the latest checkpoint
recordand PANICs?
 

Regards
Takayuki Tsunakawa






-- 
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: Michael Paquier
Date:
Subject: [HACKERS] Implementing pg_receivewal --no-sync
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] Remove secondary checkpoint