Re: Online base backup from the hot-standby

From: Steve Singer <ssinger_pg(at)sympatico(dot)ca>
To: Jun Ishiduka <ishizuka(dot)jun(at)po(dot)ntts(dot)co(dot)jp>
Cc: robertmhaas(at)gmail(dot)com, cedric(dot)villemain(dot)debian(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Online base backup from the hot-standby
Date: 2011-08-16 15:24:24
Message-ID: BLU0-SMTP257DC6BD2388E015799C748E290@phx.gbl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(dot)jun(at)po(dot)ntts(dot)co(dot)jp
> --------------------------------------------
>
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Urbański 2011-08-16 15:35:05 Re: plpython crash
Previous Message Peter Geoghegan 2011-08-16 15:22:15 Re: Re: Should we have an optional limit on the recursion depth of recursive CTEs?