Re: Logging WAL when updating hintbit

From: Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Logging WAL when updating hintbit
Date: 2013-11-15 02:56:17
Message-ID: CAD21AoB_+uLbaQubCgihoKip42sh=uqjaYFPU4p6cksoZyn=8Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 14, 2013 at 3:53 PM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Thu, Nov 14, 2013 at 3:02 PM, Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)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.
> Is 'all' a name really suited? It looks too general. I don't have a
> name on top of my mind but what about something like full_pages or
> something similar...

Yes, I'm worried about name of value.
But 'full_pages' sounds good for me.

>
>> This wal_level is infrastructure for fast failback. (i.g., without fresh backup)
>> It need to cooperate with pg_rewind.
> I am not sure that using as reason the possible interactions of a
> contrib module not in core is a reason sufficient to justify the
> presence of a new wal_level, and pg_rewind is still a young solution
> that needs to be improved. So such a patch looks premature IMO, but
> the idea is interesting and might cover many needs for external
> projects.
>
>> Not only that, I think it will be profitable infrastructure for
>> differential backup.
> Yep, agreed. This might help some projects in this area.
>
>> And it leads to improve performance at standby server side. Because
>> the standby server doesn't update hintbit by itself, but FPW is
>> replicated to standby server and applied.
> It would be interesting to see some numbers here.

I think this patch provide several benefit for feature. The fast
failback with pg_rewind is one of them.
If I want to provide only the fast failback with pg_rewind, this patch
logs too much information.
Just logging changed block number is enough for that.

As you said pg_rewind is still a young solution. But It very cool and
flexible solution.
I'm going to improve pg_rewind actively.

>
> This is clearly a WIP patch so it does not matter now, but if you
> submit it later on, be sure to add some comments in bufmgr.c as well
> as documentation for the new option.

Yes, will do.

--
Regards,

-------
Sawada Masahiko

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2013-11-15 03:00:08 Autoconf 2.69 update
Previous Message Michael Paquier 2013-11-15 02:55:16 Database disconnection and switch inside a single bgworker