On Sun, Nov 24, 2013 at 6:02 AM, Jeff Davis <pg...@j-davis.com> wrote: > On Tue, 2013-11-19 at 11:42 -0500, Robert Haas wrote: > My take is that configuration options should be used to serve different > use cases. One thing I like about postgres is that it doesn't have > options for the sake of options. > > The trade-off here seems to be: if you want fast failback, you have to > write more WAL during normal operation. But it's not clear to me which > one I should choose for a given installation. If there's a lot of data, > then fast failback is nice, but then again, logging the hint bits on a > large amount of data might be painful during normal operation. The only > time the choice is easy is when you already have checksums enabled. > > I think we should work some more in this area first so we can end up > with something that works for everyone; or at least a more clear choice > to offer users. My hope is that it will go something like: > > 1. We get more reports from the field about checksum performance > 2. pg_rewind gets some more attention > 3. we find a way to upgrade a replica set using pg_upgrade and pg_rewind > so that the replicas do not all need a new basebackup after an upgrade > 4. We further mitigate the performance impact of logging all page > modifications > 5. We eventually see that the benefits of logging all page modifications > outweigh the performance cost for most people, and start recommending to > most people > 6. The other WAL levels become more specialized for single, unreplicated > instances > > That's just a hope, of course, but we've made some progress and I think > it's a plausible outcome. As it stands, the replica re-sync after any > failover or upgrade seems to be a design gap. > > All that being said, I don't object to this option -- I just want it to > lead us somewhere. Not be another option that we keep around forever > with conflicting recommendations about how to set it. >
Thank you for feedback. I agree with you. We need to more report regarding checksum performance first. I will do that. I attached the new version patch which adds separated parameter 'enable_logging_hintbit'. It works same as previous patch, just independence from wal_level and name is changed. One changed behave is that it doesn't work together with 'minimal' wal_level. Regards, ------- Sawada Masahiko
log_hint_bit_wal_v3.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
