Re: Online base backup from the hot-standby - Mailing list pgsql-hackers

From Steve Singer
Subject Re: Online base backup from the hot-standby
Date
Msg-id BLU0-SMTP257DC6BD2388E015799C748E290@phx.gbl
Whole thread Raw
In response to Re: Online base backup from the hot-standby  (Jun Ishiduka <ishizuka.jun@po.ntts.co.jp>)
Responses Re: Online base backup from the hot-standby
List pgsql-hackers
On 11-08-16 02:09 AM, Jun Ishiduka wrote:
>
> Thanks. 
>
> This has the following two problems.
>  * pg_start_backup() must set 'on' to full_page_writes of the master that 
>    is actual writing of the WAL, but not the standby.
Is there any way to tell from the WAL segments if they contain the full
page data? If so could you verify this on the second slave when it is
brought up? Or can you track this on the first slave and produce an
error in either pg_start_backup or pg_stop_backup()

I see in xlog.h XLR_BKP_REMOVABLE, the comment above it says that this
flag is used to indicate that the archiver can compress the full page
blocks to non-full page blocks. I am not familiar with where in the code
this actually happens but will this cause issues if the first standby is
processing WAL files from the archive?


>  * The standby doesn't need to connect to the master that's actual writing 
>    WAL.
>    (Ex. Standby2 in Cascade Replication: Master - Standby1 - Standby2)
>
> I'm worried how I should clear these problems.
>
> Regards.
>
> --------------------------------------------
> Jun Ishizuka
> NTT Software Corporation
> TEL:045-317-7018
> E-Mail: ishizuka.jun@po.ntts.co.jp
> --------------------------------------------
>
>
>



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Re: Should we have an optional limit on the recursion depth of recursive CTEs?
Next
From: Jan Urbański
Date:
Subject: Re: plpython crash