Skip site navigation (1) Skip section navigation (2)

Re: Online base backup from the hot-standby

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Steve Singer <ssinger_pg(at)sympatico(dot)ca>, Jun Ishiduka <ishizuka(dot)jun(at)po(dot)ntts(dot)co(dot)jp>, magnus(at)hagander(dot)net, heikki(dot)linnakangas(at)enterprisedb(dot)com, pgsql-hackers(at)postgresql(dot)org, robertmhaas(at)gmail(dot)com, cedric(dot)villemain(dot)debian(at)gmail(dot)com
Subject: Re: Online base backup from the hot-standby
Date: 2012-01-24 09:51:13
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Mon, Jan 23, 2012 at 10:11 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On Mon, Jan 23, 2012 at 10:29 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> On Fri, Jan 20, 2012 at 11:34 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>>> On Fri, Jan 20, 2012 at 12:54 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>>>> Thanks for the review!
>>>> On Fri, Jan 20, 2012 at 8:15 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>>>>> I'm looking at this patch and wondering why we're doing so many
>>>>> press-ups to ensure full_page_writes parameter is on. This will still
>>>>> fail if you use a utility that removes the full page writes, but fail
>>>>> silently.
>>>>> I think it would be beneficial to explicitly check that all WAL
>>>>> records have full page writes actually attached to them until we
>>>>> achieve consistency.
>>>> I agree that it's worth adding such a safeguard. That can be a self-contained
>>>> feature, so I'll submit a separate patch for that, to keep each patch small.
>>> Maybe, but you mean do this now as well? Not sure I like silent errors.
>> If many people think the patch is not acceptable without such a safeguard,
>> I will do that right now. Otherwise, I'd like to take more time to do
>> that, i.e.,
>> add it to 9.2dev Oepn Items.
>> I've not come up with good idea. Ugly idea is to keep track of all replays of
>> full_page_writes for every buffer pages (i.e., prepare 1-bit per buffer page
>> table and set the specified bit to 1 when full_page_writes is applied),
>> and then check whether full_page_writes has been already applied when
>> replaying normal WAL record... Do you have any better idea?
> Not sure.
> I think the only possible bug here is one introduced by an outside utility.
> In that case, I don't think it should be the job of the backend to go
> too far to protect against such atypical error. So if we can't solve
> it fairly easily and with no overhead then I'd say lets skip it. We
> could easily introduce a bug here just by having faulty checking code.
> So lets add it to 9.2 open items as a non-priority item.


> I'll proceed to commit for this now.

Thanks a lot!


Fujii Masao
NTT Open Source Software Center

In response to


pgsql-hackers by date

Next:From: Fujii MasaoDate: 2012-01-24 10:19:33
Subject: Re: WAL Restore process during recovery
Previous:From: Simon RiggsDate: 2012-01-24 09:49:16
Subject: Re: WAL Restore process during recovery

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group