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

Re: Online base backup from the hot-standby

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(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-23 13:11:04
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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.

 Simon Riggs         
 PostgreSQL Development, 24x7 Support, Training & Services

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2012-01-23 13:11:10
Subject: Re: Online base backup from the hot-standby
Previous:From: Robert HaasDate: 2012-01-23 13:09:11
Subject: Re: PG-Strom - A GPU optimized asynchronous executor module

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