On Sun, Nov 24, 2013 at 6:02 AM, Jeff Davis <pgsql@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