Re: Production block comparison facility - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Production block comparison facility
Date
Msg-id CA+U5nMJHRkM-Pz1LG3792TaYtFeMMdKtq4KSyhVezo0EzbVvRw@mail.gmail.com
Whole thread Raw
In response to Re: Production block comparison facility  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Responses Re: Production block comparison facility
List pgsql-hackers
On 29 July 2014 11:30, Heikki Linnakangas <hlinnakangas@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.

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ]
Next
From: Amit Kapila
Date:
Subject: Re: Proposal: Incremental Backup