Re: Allow WAL information to recover corrupted pg_controldata - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Allow WAL information to recover corrupted pg_controldata
Date
Msg-id 17994.1340262651@sss.pgh.pa.us
Whole thread Raw
In response to Re: Allow WAL information to recover corrupted pg_controldata  (Amit Kapila <amit.kapila@huawei.com>)
Responses Re: Allow WAL information to recover corrupted pg_controldata  (Amit Kapila <amit.kapila@huawei.com>)
Re: Allow WAL information to recover corrupted pg_controldata  (Amit Kapila <amit.kapila@huawei.com>)
List pgsql-hackers
Amit Kapila <amit.kapila@huawei.com> writes:
>> The reason I'm concerned about selecting a next-LSN that's certainly beyond every LSN in the database is that not
doing
 
>> so could result in introducing further corruption, which would be entirely avoidable with more care in choosing the

>> next-LSN.

> The further corruption can only be possible when we replay some wrong
> WAL by selecting wrong LSN.

No, this is mistaken.  Pages in the database that have LSN ahead of
where the server thinks the end of WAL is cause lots of problems
unrelated to replay; for example, inability to complete a checkpoint.
That might not directly lead to additional corruption, but consider
the case where such a page gets further modified, and the server decides
it doesn't need to create a full-page image because the LSN is ahead of
where the last checkpoint was.  A crash or two later, you have new
problems.

(Admittedly, once you've run pg_resetxlog you're best advised to just be
trying to dump what you've got, and not modify it more.  But sometimes
you have to hack the data just to get pg_dump to complete.)
        regards, tom lane


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Pruning the TODO list
Next
From: Heikki Linnakangas
Date:
Subject: Re: SP-GiST for ranges based on 2d-mapping and quad-tree