Re: Logging WAL when updating hintbit

From: Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Logging WAL when updating hintbit
Date: 2013-11-25 12:02:47
Message-ID: CAD21AoDkPkm+5AB2Hx77SDxi0QG9Kig6Lr_aQkUcYD--=ihkwA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Nov 24, 2013 at 6:02 AM, Jeff Davis <pgsql(at)j-davis(dot)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

Attachment Content-Type Size
log_hint_bit_wal_v3.patch application/octet-stream 7.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2013-11-25 13:35:13 Re: [GENERAL] pg_upgrade ?deficiency
Previous Message Andres Freund 2013-11-25 11:47:12 Re: Errors on missing pg_subtrans/ files with 9.3