On Tue, Dec 3, 2013 at 5:34 PM, Sawada Masahiko <sawada.m...@gmail.com> wrote: > 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: >> >> 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. >
I attached the patch which have modified based on Robert suggestion, and fixed typo. Regards, ------- Sawada Masahiko
log_hint_bit_wal_v6.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
