On Tue, Dec 3, 2013 at 3:30 PM, Sawada Masahiko <sawada.mshk@gmail.com> wrote:
> On Tue, Dec 3, 2013 at 12:02 PM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
>>> Indeed, I forgot this code path. Completing for
>>> saving the state and xlog_redo for replay would be enough.
>> Wait a minute, I retract this argument. By using this method a master
>> server would be able to produce WAL files with inconsistent hint bit
>> data when they are replayed if log_hint_bits is changed after a
>> restart of the master.
>
> How case does it occur?
> I think pg_rewind can disagree to rewind if log_hint_bits is changed to 'OFF'.
> Is this not enough?
After more thinking...
Before performing a rewind on a node, what we need to know is that
log_hint_bits was set to true when WAL forked, because of the issue
that Robert mentioned here:
http://www.postgresql.org/message-id/519E5493.5060800@vmware.com
It does not really matter if the node used log_hint_bits set to false
in its latest state (Node to-be-rewinded might have been restarted
after WAL forked).
So, after more thinking, yes using XLOG_PARAMETER_CHANGE and
PGC_POSTMASTER for this parameter would be enough. However on the
pg_rewind side we would need to track the value of log_hint_bits when
analyzing the WALs and ensure that it was set to true at fork point.
This is not something that the core should about though.
--
Michael