On Thu, Jul 31, 2014 at 2:59 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > On 29 July 2014 11:30, Heikki Linnakangas <hlinnakan...@vmware.com> wrote: > >> I don't understand how this works. A full-page image contains the new page >> contents *after* the WAL-logged operation. For example, in a heap insert, >> the full-page image contains the new tuple. How can you compare that with >> what's on the disk already? >> >> ISTM you'd need to log two full-page images for every WAL record. A before >> image and an after image. Then you could do a lot of checking: >> >> 1. the before image should match what's on disk already >> 2. the result after applying the WAL record should match the after image. >> >> That would be more handy than the approach I used, where the page images are >> logged to a separate file. You wouldn't need to deal with any new files, as >> all the data is in the WAL. Verification would be done directly in the >> standby, with no need to run any extra programs. > > It doesn't matter whether we take a before or after image of the page. > > What is important is that we make the check on the standby at the same > point as the full page was taken on the master. After all, the pages > are marked as removable. > > Given the pages are after images, then we just make the check after > applying WAL. > > So I don't see the need for two full page images. By doing so you definitely need an additional mode for full-page writes: one certifying that process does not apply this FPW because it wants to compare it to current page after applying the WALs. This increases the footprint of the feature on code because all the code paths where RestoreBackupBlock is called need to be bypassed. -- Michael
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
