On Mon, Dec 2, 2013 at 12:54 AM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Thu, Nov 28, 2013 at 9:42 PM, Sawada Masahiko <sawada.m...@gmail.com> > wrote: >> I attached new version patch which have modify typos and added >> documentation patch. >> The documentation part of patch is implemented by Samrat Revagade. > Thanks for the new version. The documentation still has some typo: > - is ,<literal>off</> => is <literal>off</> > > I have been pondering about this feature over the weekend and I have > to admit that the approach using a GUC that can be modified after > server initialization is not suited. What we want with this feature is > to be able to include hint bits in WAL to perform WAL differential > operations which is in some way what for example pg_rewing is doing by > analyzing the relation blocks modified since the WAL fork point of a > master with one of its promoted slave. But if this parameter can be > modified by user at will, a given server could finish with a set of > WAL files having inconsistent hint bit data (some files might have the > hint bits, others not), which could create corrupted data when they > are replayed in recovery.
Yep, that's a problem. > Considering that, it would make more sense to have this option > settable with initdb only and not changeable after initialization, in > the same fashion as checksums. Having a GUC that can be used to check > if this option is set or not using a SQL command could be an > additional patch on top of the core feature. > > This does not mean of course that this patch has to be completely > reworked as the core part of the patch, the documentation and the > control file part would remain more or less the same. Forcing it to be done only an initdb-time is excessive. I think you can just make it PGC_POSTMASTER and have it participate in the XLOG_PARAMETER_CHANGE mechanism. pg_rewind can check that it's set in the control file before agreeing to rewind. As long as it was set at the time the master last entered read-write mode (which is what the XLOG_PARAMETER_CHANGE stuff does) you should be fine, unless of course I haven't had enough caffeine this morning, which is certainly possible. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers