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
> --------------------------------------------
>
>
>
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? |