Re: Logging WAL when updating hintbit

On Mon, Dec 2, 2013 at 12:54 AM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Thu, Nov 28, 2013 at 9:42 PM, Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)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.

Yep, that's a problem.

> 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.

Forcing it to be done only an initdb-time is excessive. I think you
can just make it PGC_POSTMASTER and have it participate in the
XLOG_PARAMETER_CHANGE mechanism. pg_rewind can check that it's set in
the control file before agreeing to rewind. As long as it was set at
the time the master last entered read-write mode (which is what the
XLOG_PARAMETER_CHANGE stuff does) you should be fine, unless of course
I haven't had enough caffeine this morning, which is certainly
possible.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company