On Tue, 2013-11-19 at 11:42 -0500, Robert Haas wrote:
> On Thu, Nov 14, 2013 at 1:02 AM, Sawada Masahiko <sawada.mshk@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
