From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Michael Paquier <michael@paquier.xyz>
To: Sergei Kornilov <sk@zsrv.org>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: could recovery_target_timeline=latest be the default in standby mode?
Date: Thu, 27 Dec 2018 12:02:34 +0100
Message-ID: <249bd41d-0385-3038-4394-a42f00e1a045@2ndquadrant.com> (raw)
In-Reply-To: <20181221233819.GE1948@paquier.xyz>
References: <6dd2c23a-4162-8469-410f-bfe146e28c0c@2ndquadrant.com>
<7495701545389660@sas1-87f9feb8d943.qloud-c.yandex.net>
<20181221233819.GE1948@paquier.xyz>
On 22/12/2018 00:38, Michael Paquier wrote:
> On Fri, Dec 21, 2018 at 01:54:20PM +0300, Sergei Kornilov wrote:
>> I am +1 for recovery_target_timeline=latest by default. This is
>> common case in my opinion.
>
> I agree also that switching to the latest timeline should be the
> default. People get confused because of the current default.
How about this patch then?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachments:0001-Always-use-latest-timeline-in-standby-mode.patch (text/plain, 7.4K) download
From 5fd266a61c63104d8f3f4cd3e19bfc99fd22ba21 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter_e@gmx.net>
Date: Thu, 27 Dec 2018 11:49:47 +0100
Subject: [PATCH] Always use latest timeline in standby mode
In standby mode, ignore the setting of recovery_target_timeline and
always behave as if 'latest' was specified.
---
doc/src/sgml/config.sgml | 15 ++++++++++++---
doc/src/sgml/high-availability.sgml | 8 ++------
src/backend/access/transam/xlog.c | 7 +++++++
src/bin/pg_rewind/RewindTest.pm | 2 --
src/test/recovery/t/004_timeline_switch.pl | 1 -
src/test/recovery/t/009_twophase.pl | 12 ------------
src/test/recovery/t/012_subtransactions.pl | 12 ------------
7 files changed, 21 insertions(+), 36 deletions(-)
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgmlindex e94b305add..76a83246ee 100644--- a/doc/src/sgml/config.sgml+++ b/doc/src/sgml/config.sgml@@ -3352,13 +3352,22 @@ <title>Recovery Target</title>
<para>
Specifies recovering into a particular timeline. The default is
to recover along the same timeline that was current when the
- base backup was taken. Setting this to <literal>latest</literal> recovers- to the latest timeline found in the archive, which is useful in- a standby server. Other than that you only need to set this parameter+ base backup was taken. Setting this to <literal>latest</literal> recovers+ to the latest timeline found in the archive.+ </para>++ <para>+ You only need to set this parameter
in complex re-recovery situations, where you need to return to
a state that itself was reached after a point-in-time recovery.
See <xref linkend="backup-timelines"/> for discussion.
</para>
++ <para>+ In standby mode, this parameter is ignored and the latest timeline is+ always used. This allows a standby to follow timeline changes in+ upstream servers.+ </para>
</listitem>
</varlistentry>
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgmlindex d8fd195da0..47a93aef5b 100644--- a/doc/src/sgml/high-availability.sgml+++ b/doc/src/sgml/high-availability.sgml@@ -689,10 +689,7 @@ <title>Setting Up a Standby Server</title>
server (see <xref linkend="backup-pitr-recovery"/>). Create a file
<filename>standby.signal</filename> in the standby's cluster data
directory. Set <xref linkend="guc-restore-command"/> to a simple command to copy files from
- the WAL archive. If you plan to have multiple standby servers for high- availability purposes, set <varname>recovery_target_timeline</varname> to- <literal>latest</literal>, to make the standby server follow the timeline change- that occurs at failover to another standby.+ the WAL archive.
</para>
<note>
@@ -1023,8 +1020,7 @@ <title>Cascading Replication</title>
<para>
If an upstream standby server is promoted to become new master, downstream
- servers will continue to stream from the new master if- <varname>recovery_target_timeline</varname> is set to <literal>'latest'</literal>.+ servers will continue to stream from the new master.
</para>
<para>
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.cindex 5729867879..315fff48c7 100644--- a/src/backend/access/transam/xlog.c+++ b/src/backend/access/transam/xlog.c@@ -5420,6 +5420,13 @@ validateRecoveryParameters(void)
!EnableHotStandby)
recoveryTargetAction = RECOVERY_TARGET_ACTION_SHUTDOWN;
+ /*+ * In standby mode, always use latest timeline, ignoring+ * recovery_target_timeline setting.+ */+ if (StandbyModeRequested)+ recoveryTargetTimeLineGoal = RECOVERY_TARGET_TIMELINE_LATEST;+
/*
* If user specified recovery_target_timeline, validate it or compute the
* "latest" value. We can't do this until after we've gotten the restore
diff --git a/src/bin/pg_rewind/RewindTest.pm b/src/bin/pg_rewind/RewindTest.pmindex 3d07da5d94..85cae7e47b 100644--- a/src/bin/pg_rewind/RewindTest.pm+++ b/src/bin/pg_rewind/RewindTest.pm@@ -161,7 +161,6 @@ sub create_standby
$node_standby->append_conf(
"postgresql.conf", qq(
primary_conninfo='$connstr_master application_name=rewind_standby'
-recovery_target_timeline='latest'
));
$node_standby->set_standby_mode();
@@ -273,7 +272,6 @@ sub run_pg_rewind
$node_master->append_conf(
'postgresql.conf', qq(
primary_conninfo='port=$port_standby'
-recovery_target_timeline='latest'
));
$node_master->set_standby_mode();
diff --git a/src/test/recovery/t/004_timeline_switch.pl b/src/test/recovery/t/004_timeline_switch.plindex 79cbffb827..2b315854bc 100644--- a/src/test/recovery/t/004_timeline_switch.pl+++ b/src/test/recovery/t/004_timeline_switch.pl@@ -51,7 +51,6 @@
$node_standby_2->append_conf(
'postgresql.conf', qq(
primary_conninfo='$connstr_1 application_name=@{[$node_standby_2->name]}'
-recovery_target_timeline='latest'
));
$node_standby_2->restart;
diff --git a/src/test/recovery/t/009_twophase.pl b/src/test/recovery/t/009_twophase.plindex dac2d4ec0d..2be1afcd8b 100644--- a/src/test/recovery/t/009_twophase.pl+++ b/src/test/recovery/t/009_twophase.pl@@ -229,10 +229,6 @@ sub configure_and_reload
# restart old master as new standby
$cur_standby->enable_streaming($cur_master);
-$cur_standby->append_conf(- 'postgresql.conf', qq(-recovery_target_timeline='latest'-));
$cur_standby->start;
###############################################################################
@@ -267,10 +263,6 @@ sub configure_and_reload
# restart old master as new standby
$cur_standby->enable_streaming($cur_master);
-$cur_standby->append_conf(- 'postgresql.conf', qq(-recovery_target_timeline='latest'-));
$cur_standby->start;
$cur_master->psql('postgres', "COMMIT PREPARED 'xact_009_11'");
@@ -307,10 +299,6 @@ sub configure_and_reload
# restart old master as new standby
$cur_standby->enable_streaming($cur_master);
-$cur_standby->append_conf(- 'postgresql.conf', qq(-recovery_target_timeline='latest'-));
$cur_standby->start;
$cur_master->psql('postgres', "COMMIT PREPARED 'xact_009_12'");
diff --git a/src/test/recovery/t/012_subtransactions.pl b/src/test/recovery/t/012_subtransactions.plindex e26cc9c2ce..c184553694 100644--- a/src/test/recovery/t/012_subtransactions.pl+++ b/src/test/recovery/t/012_subtransactions.pl@@ -119,10 +119,6 @@
# restore state
($node_master, $node_standby) = ($node_standby, $node_master);
$node_standby->enable_streaming($node_master);
-$node_standby->append_conf(- 'postgresql.conf', qq(-recovery_target_timeline='latest'-));
$node_standby->start;
$node_standby->psql(
'postgres',
@@ -170,10 +166,6 @@
# restore state
($node_master, $node_standby) = ($node_standby, $node_master);
$node_standby->enable_streaming($node_master);
-$node_standby->append_conf(- 'postgresql.conf', qq(-recovery_target_timeline='latest'-));
$node_standby->start;
$psql_rc = $node_master->psql('postgres', "COMMIT PREPARED 'xact_012_1'");
is($psql_rc, '0',
@@ -211,10 +203,6 @@
# restore state
($node_master, $node_standby) = ($node_standby, $node_master);
$node_standby->enable_streaming($node_master);
-$node_standby->append_conf(- 'postgresql.conf', qq(-recovery_target_timeline='latest'-));
$node_standby->start;
$psql_rc = $node_master->psql('postgres', "ROLLBACK PREPARED 'xact_012_1'");
is($psql_rc, '0',
--
2.20.1
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: peter.eisentraut@2ndquadrant.com, michael@paquier.xyz, sk@zsrv.org
Subject: Re: could recovery_target_timeline=latest be the default in standby mode?
In-Reply-To: <249bd41d-0385-3038-4394-a42f00e1a045@2ndquadrant.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox