Re: Logging WAL when updating hintbit - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Logging WAL when updating hintbit
Date
Msg-id CAB7nPqQcG+dim5492h_V7iQT0c-8tX0Ci0f1mKkPitsqG19Vog@mail.gmail.com
Whole thread Raw
In response to Re: Logging WAL when updating hintbit  (Sawada Masahiko <sawada.mshk@gmail.com>)
Responses Re: Logging WAL when updating hintbit
List pgsql-hackers
On Thu, Nov 28, 2013 at 9:42 PM, Sawada Masahiko <sawada.mshk@gmail.com> wrote:
> I attached new version patch which have modify typos and added
> documentation patch.
> The documentation part of patch is implemented by Samrat Revagade.
Thanks for the new version. The documentation still has some typo:
- is ,<literal>off</> => is <literal>off</>

I have been pondering about this feature over the weekend and I have
to admit that the approach using a GUC that can be modified after
server initialization is not suited. What we want with this feature is
to be able to include hint bits in WAL to perform WAL differential
operations which is in some way what for example pg_rewing is doing by
analyzing the relation blocks modified since the WAL fork point of a
master with one of its promoted slave. But if this parameter can be
modified by user at will, a given server could finish with a set of
WAL files having inconsistent hint bit data (some files might have the
hint bits, others not), which could create corrupted data when they
are replayed in recovery.

Considering that, it would make more sense to have this option
settable with initdb only and not changeable after initialization, in
the same fashion as checksums. Having a GUC that can be used to check
if this option is set or not using a SQL command could be an
additional patch on top of the core feature.

This does not mean of course that this patch has to be completely
reworked as the core part of the patch, the documentation and the
control file part would remain more or less the same.

Regards,
-- 
Michael



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist
Next
From: Michael Paquier
Date:
Subject: In-core regression tests for replication, cascading, archiving, PITR, etc.