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-20 11:15:55
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
On Tue, Jan 17, 2012 at 10:38 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Fri, Jan 13, 2012 at 5:02 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> The amount of code changes to allow pg_basebackup to make a backup from
>> the standby seems to be small. So I ended up merging that changes and the
>> infrastructure patch. WIP patch attached. But I'd happy to split the patch again
>> if you want.
> Attached is the updated version of the patch. I wrote the limitations of
> standby-only backup in the document and changed the error messages.

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

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.

Surprised to see XLOG_FPW_CHANGE is there again after I objected to it
and it was removed. Not sure why? We already track other parameters
when they change, so I don't want to introduce a whole new WAL record
for each new parameter whose change needs tracking.

Please make a note for committer that wal version needs bumping.

I think its probably time to start a README.recovery to explain why
this works the way it does. Other changes can then start to do that as
well, so we can keep this to sane levels of complexity.

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

In response to


pgsql-hackers by date

Next:From: Magnus HaganderDate: 2012-01-20 11:24:29
Subject: Re: IDLE in transaction introspection
Previous:From: Fujii MasaoDate: 2012-01-20 11:04:29
Subject: Re: Online base backup from the hot-standby

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