On Sat, Sep 10, 2016 at 8:33 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Sat, Sep 10, 2016 at 3:19 AM, Michael Paquier > <michael.paqu...@gmail.com> wrote: >> On Fri, Sep 9, 2016 at 4:01 PM, Kuntal Ghosh <kuntalghosh.2...@gmail.com> >> wrote: >>>>> - If WAL consistency check is enabled for a rmgrID, we always include >>>>> the backup image in the WAL record. >>>> >>>> What happens if wal_consistency has different settings on a standby >>>> and its master? If for example it is set to 'all' on the standby, and >>>> 'none' on the master, or vice-versa, how do things react? An update of >>>> this parameter should be WAL-logged, no? >>>> >>> It is possible to set wal_consistency to 'All' in master and any other >>> values in standby. But, the scenario you mentioned will cause error in >>> standby since it may not get the required backup image for wal >>> consistency check. I think that user should be responsible to set >>> this value correctly. We can improve the error message to make the >>> user aware of the situation. >> >> Let's be careful here. You should as well consider things from the >> angle that some parameter updates are WAL-logged as well, like >> wal_level with the WAL record XLOG_PARAMETER_CHANGE. > > It seems entirely unnecessary for the master and the standby to agree > here. I think what we need is two GUCs. One of them, which affects > only the master, controls whether the validation information is > including in the WAL, and the other, which affects only the standby, > affects whether validation is performed when the necessary information > is present. >
I think from the clarity perspective, this option sounds good, but I am slightly afraid that it might be inconvenient for users to set the different values for these two parameters. > Or maybe skip the second one and just decree that > standbys will always validate if the necessary information is present. Sounds like a better alternative and probably easier to configure for users. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
