Re: Logging WAL when updating hintbit

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Jeff Davis <pgsql(at)j-davis(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Logging WAL when updating hintbit
Date: 2013-12-02 05:54:09
Message-ID: CAB7nPqQcG+dim5492h_V7iQT0c-8tX0Ci0f1mKkPitsqG19Vog@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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

In response to

Responses

Browse pgsql-hackers by date

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