Re: Online base backup from the hot-standby

Simon Riggs <simon@2ndquadrant.com>

From: Simon Riggs <simon@2ndquadrant.com>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: Steve Singer <ssinger_pg@sympatico.ca>, Jun Ishiduka <ishizuka.jun@po.ntts.co.jp>, magnus@hagander.net, heikki.linnakangas@enterprisedb.com, pgsql-hackers@postgresql.org, robertmhaas@gmail.com, cedric.villemain.debian@gmail.com
Date: 2012-01-20T11:15:55Z
Lists: pgsql-hackers
On Tue, Jan 17, 2012 at 10:38 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Fri, Jan 13, 2012 at 5:02 PM, Fujii Masao <masao.fujii@gmail.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
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.

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                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services