On Thu, Nov 14, 2013 at 3:53 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Thu, Nov 14, 2013 at 3:02 PM, 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.
> 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
