On Tue, Dec 3, 2013 at 4:28 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> 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.
Yep, pg_rewind needs to track the value of wal_log_hintbits.
I think value of wal_log_hintbits always needs to have been set true
after fork point.
And if wal_log_hintbits is set false when we perform pg_rewind, we can not that.
Regards,
-------
Sawada Masahiko