From: Robert Haas [mailto:robertmh...@gmail.com] Sent: Friday, June 22, 2012 8:59 PM On Fri, Jun 22, 2012 at 5:25 AM, Amit Kapila <amit.kap...@huawei.com> wrote: >> Based on the discussion and suggestions in this mail chain, following features can be implemented: >> >> 1. To compute the value of max LSN in data pages based on user input whether he wants it for an individual file, >> a particular directory or whole database. >> >> 2a. To search the available WAL files for the latest checkpoint record and prints the value. >> 2b. To search the available WAL files for the latest checkpoint record and recreates a pg_control file pointing at that checkpoint. >> >> I have kept both options to address different kind of corruption scenarios.
> I think I can see all of those things being potentially useful. There > are a couple of pending patches that will revise the WAL format > slightly; not sure how much those are likely to interfere with any > development you might do on (2) in the meantime. Below is the details of Option-2, for Option-1, I will send mail separately New option for pg_resetxlog: ----------------------------- 1. Introduce option -r to restore the control file if possible and print those values. 3. User need to give option -f along with -r to rewrite the control file from WAL files. 2. If not able to get the control information from WAL files then the control data will be guessed and proceedes as normal reset xlog. 4. If the control information is restored, then the option -l is ignored. Design for new Option: ---------------------- 1. Validate the pg_xlog directory before proceeding of restoring control values. if the directory is invalid then the control values will be guessed. 2. Read the pg_xlog directory and read all the existing files. 3. If it is a valid xlog file then add it to a list in an increasing order, Otherwise the file is ignored and continue to the next file. 4. Try to find the last timestamp file from the list to start reading for a checkpoint record. 5. Read the first page from the file and validate it. if the validation fails the restore happens with guessed values. 6. Read the first record as start of the record from the identified first xlog file. 7. If the first record is a continuation record from a previous record then ignore the record and continue to the next record. 8. After getting the entire record then the record is validated, if it is not a valid record searching for the next record will be stopped and the control values will be guessed. 9. Search all the files to the end of the last file to get the latest checkpoint record. 10. While searching for the record, if it is not reaching the last file (there is missing file or invalid record) then treat this scenario as a failure of finding the checkpoint record and go for guessing the control values. 11. After finding the last checkpoint record, update the checkpoint record information in the control file. Implementation: ---------------- 1. We need to use most of the functionality of functions mentioned below. One way is to duplicate the code of these functions related to functionality required by pg_resetxlog in pg_resetxlog module. I have checked other modules also but didn't find how we can use common functionality in server utility from backend code. Could you please point me for the appropriate way for doing it. The list of functions: 1. ValidateXLOGDirectoryStructure 2. XLogPageRead 3. ReadRecord 4. RecordIsValid 5. ValidXLOGPageHeader 6. ValidXLogRecordHeader Suggestions/Comments/Thoughts? With Regards, Amit Kapila. -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers