On Tue, 2013-11-19 at 11:42 -0500, Robert Haas wrote: > On Thu, Nov 14, 2013 at 1:02 AM, Sawada Masahiko <sawada.m...@gmail.com> > wrote: > > I attached patch adds new wal_level 'all'. > > If wal_level is set 'all', the server logs WAL not only when wal_level > > is set 'hot_standby' ,but also when updating hint bit. > > That is, we will be able to know all of the changed block number by > > reading the WALs. > > This wal_level is infrastructure for fast failback. (i.g., without fresh > > backup) > > It need to cooperate with pg_rewind. > > I'm also not 100% sure we want it, but let's hear what others think.
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. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers