On Tue, Dec 3, 2013 at 4:28 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Tue, Dec 3, 2013 at 3:30 PM, Sawada Masahiko <sawada.m...@gmail.com> wrote: >> On Tue, Dec 3, 2013 at 12:02 PM, Michael Paquier >> <michael.paqu...@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.5060...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
