From: | Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com> |
---|---|
To: | David Steele <david(at)pgmasters(dot)net> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Skip recovery/standby signal files in pg_basebackup |
Date: | 2019-09-30 08:49:58 |
Message-ID: | CAE9k0Pnz_Wu=PtpOtGL=qC33Ow+jwtG2VDuRzYQW5mgBAgmk1A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi David,
On Sat, Sep 28, 2019 at 12:23 AM David Steele <david(at)pgmasters(dot)net> wrote:
>
> Hackers,
>
> Restoring these files could cause surprising behaviors so it seems best
> to let the restore process create them when needed.
>
Could you please let us know what is the surprising behaviour you are
talking about here when including recovery/standby signal files in
pg_basebackup output.
If including recovery.conf in pg_basebackup output earlier wasn't a
problem then why including recovery/standby.signal should be a
problem.
Your patch is just trying to skip standby.signal or recovery.signal
files when the base backup is either taken on standby server or it is
taken on the server where the PITR is still going on or may be paused.
What would be the behaviour with your patch when *-R* option is used
with pg_basebackup to take backup from standby server ? Won't it
create a standby.signal file.
> Patch is attached.
>
--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2019-09-30 08:50:03 | Re: recovery_min_apply_delay in archive recovery causes assertion failure in latch |
Previous Message | Konstantin Knizhnik | 2019-09-30 08:29:44 | Re: Removing unneeded self joins |