On Wed, Jul 23, 2014 at 11:14 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > Things could be refactored and improved for sure, but this patch is already > useful as-is so I am going to add it to the next commit fest.
After some more investigation, I am going to mark this patch as "Returned with feedback" for the time being (mainly to let it show up on the commit fest app and for the sake of archives), Mainly for two reasons: - We can do better than what I sent: instead of checking if the FPW and the current page are somewhat consistent, we could actually check if the current page is equal with the FPW after applying WAL on it. In order to do that, we would need to bypass the FPW replay and to apply WAL on the current page (if the page is already initialized), then control RestoreBackupBlock (or its equivalent) that with an additional flag to tell that block is "not restored, but can get WAL applied to it safely". Then a comparison with the FPW contained in the WAL record can be made. - The patch of Heikki to change the WAL APIs and track more easily the blocks changes is going to make this implementation far easier. It also improves the status checks on which block has been restored, so it is more easily extensible for what could be done here. Regards, -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers