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

From Michael Paquier
Subject Re: Production block comparison facility
Date
Msg-id CAB7nPqQmb7HGoi-8BEM2+UughLfMRCHJdWsKa7MzG9NsSo+u_Q@mail.gmail.com
Whole thread Raw
In response to Production block comparison facility  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Production block comparison facility  (Simon Riggs <simon@2ndQuadrant.com>)
Re: Production block comparison facility  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On Sun, Jul 20, 2014 at 5:31 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> The block comparison facility presented earlier by Heikki would not be
> able to be used in production systems. ISTM that it would be desirable
> to have something that could be used in that way.
>
> ISTM easy to make these changes
>
> * optionally generate a FPW for every WAL record, not just first
> change after checkpoint
> full_page_writes = 'always'
>
> * when an FPW arrives, optionally run a check to see if it compares
> correctly against the page already there, when running streaming
> replication without a recovery target. We could skip reporting any
> problems until the database is consistent
> full_page_write_check = on
>
> The above changes seem easy to implement.
>
> With FPW compression, this would be a usable feature in production.
>
> Comments?

This is an interesting idea, and it would be easier to use than what
has been submitted for CF1. However, full_page_writes set to "always"
would generate a large amount of WAL even for small records,
increasing I/O for the partition holding pg_xlog, and the frequency of
checkpoints run on system. Is this really something suitable for
production?
Then, looking at the code, we would need to tweak XLogInsert for the
WAL record construction to always do a FPW and to update
XLogCheckBufferNeedsBackup. Then for the redo part, we would need to
do some extra operations in the area of
RestoreBackupBlock/RestoreBackupBlockContents, including masking
operations before comparing the content of the FPW and the current
page.

Does that sound right?
-- 
Michael



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: plpgsql.extra_warnings='num_into_expressions'
Next
From: "MauMau"
Date:
Subject: Re: [bug fix] Suppress "autovacuum: found orphan temp table" message