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. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers