Skip recovery/standby signal files in pg_basebackup
Hackers,
Restoring these files could cause surprising behaviors so it seems best
to let the restore process create them when needed.
Patch is attached.
--
-David
david@pgmasters.net
Attachments:
ignore-recovery-standby-signal-files-v01.patchtext/plain; charset=UTF-8; name=ignore-recovery-standby-signal-files-v01.patch; x-mac-creator=0; x-mac-type=0Download
From 1b3d95607afeb4f1fa98c3ea006f310ab68252f7 Mon Sep 17 00:00:00 2001
From: David Steele <david@pgmasters.net>
Date: Fri, 27 Sep 2019 14:49:07 -0400
Subject: [PATCH] Ignore recovery/standby signal files in pg_basebackup.
Restoring these files could cause surprising behaviors so it seems best
to let the restore process create them when needed.
---
src/backend/replication/basebackup.c | 7 +++++++
src/bin/pg_basebackup/t/010_pg_basebackup.pl | 14 +++++++++++---
2 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d0f210de8c..65075b1770 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -183,6 +183,13 @@ static const char *const excludeFiles[] =
/* Skip relation cache because it is rebuilt on startup */
RELCACHE_INIT_FILENAME,
+ /*
+ * Skip recovery/standby signal files. These files should be created after
+ * restore if they are required.
+ */
+ RECOVERY_SIGNAL_FILE,
+ STANDBY_SIGNAL_FILE,
+
/*
* If there's a backup_label or tablespace_map file, it belongs to a
* backup started by the user with pg_start_backup(). It is *not* correct
diff --git a/src/bin/pg_basebackup/t/010_pg_basebackup.pl b/src/bin/pg_basebackup/t/010_pg_basebackup.pl
index b7d36b65dd..6bccaef15a 100644
--- a/src/bin/pg_basebackup/t/010_pg_basebackup.pl
+++ b/src/bin/pg_basebackup/t/010_pg_basebackup.pl
@@ -6,7 +6,7 @@ use File::Basename qw(basename dirname);
use File::Path qw(rmtree);
use PostgresNode;
use TestLib;
-use Test::More tests => 106;
+use Test::More tests => 108;
program_help_ok('pg_basebackup');
program_version_ok('pg_basebackup');
@@ -65,7 +65,8 @@ $node->restart;
# Write some files to test that they are not copied.
foreach my $filename (
- qw(backup_label tablespace_map postgresql.auto.conf.tmp current_logfiles.tmp)
+ qw(backup_label tablespace_map postgresql.auto.conf.tmp current_logfiles.tmp
+ recovery.signal standby.signal)
)
{
open my $file, '>>', "$pgdata/$filename";
@@ -135,11 +136,18 @@ foreach my $dirname (
# These files should not be copied.
foreach my $filename (
qw(postgresql.auto.conf.tmp postmaster.opts postmaster.pid tablespace_map current_logfiles.tmp
- global/pg_internal.init))
+ global/pg_internal.init recovery.signal standby.signal))
{
ok(!-f "$tempdir/backup/$filename", "$filename not copied");
}
+# Remove recovery/standby signal files so they don't break further testing.
+foreach my $filename (qw(recovery.signal standby.signal))
+{
+ unlink("$pgdata/$filename")
+ or BAIL_OUT("unable to unlink $pgdata/backup/$filename");
+}
+
# Unlogged relation forks other than init should not be copied
ok(-f "$tempdir/backup/${baseUnloggedPath}_init",
'unlogged init fork in backup');
--
2.20.1 (Apple Git-117)
On Sat, Sep 28, 2019 at 3:53 AM David Steele <david@pgmasters.net> wrote:
Hackers,
Restoring these files could cause surprising behaviors so it seems best
to let the restore process create them when needed.
It's not a normal situation where a running postgres has either
recovery.signal or standby.signal but I'm +1 on this change for
safety.
The patch looks good to me.
Regards,
--
Masahiko Sawada
On Fri, Sep 27, 2019 at 02:52:54PM -0400, David Steele wrote:
Restoring these files could cause surprising behaviors so it seems best
to let the restore process create them when needed.Patch is attached.
When taking a base backup from a standby, we have always copied
recovery.conf if present, which would have triggered recovery (and
a standby if standby_mode was enabled). Hence always including
RECOVERY_SIGNAL_FILE would be consistent with the past behavior.
Including STANDBY_SIGNAL_FILE would be consistent with checking if
standby_mode was set or not in recovery.conf. We have replaced
standby_mode by the standby signal file, so including it if present
is consistent with the past as well, no?
--
Michael
Hi David,
On Sat, Sep 28, 2019 at 12:23 AM David Steele <david@pgmasters.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