|From:||Michael Paquier <michael(at)paquier(dot)xyz>|
|To:||David Steele <david(at)pgmasters(dot)net>|
|Cc:||Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Sergei Kornilov <sk(at)zsrv(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: could recovery_target_timeline=latest be the default in standby mode?|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Mon, Dec 31, 2018 at 01:21:00PM +0200, David Steele wrote:
> This patch looks good to me.
(Sorry for the delay here)
0001 looks fine to me.
- 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
+ to the latest timeline found in the archive. That is the default.
Isn't it useful to still mention that the default is useful especially
for standby servers?
- 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.
I think that we should still keep this recommendation as well, as well
as the one below.
- RecoveryTargetTimeLineGoal rttg = RECOVERY_TARGET_TIMELINE_CONTROLFILE;
+ RecoveryTargetTimeLineGoal rttg;
Good to remove this noise.
> Yes, that's exactly what I was thinking.
> There don't seem to be any tests for recovery_target_timeline=current. This
> is an preexisting condition but it probably wouldn't hurt to add one.
Yes, I got to wonder while looking at this patch why we don't have one
yet in 003_recovery_targets.pl. That's easy enough to do thanks to
the extra rows inserted after doing the stuff for the LSN-based
restart point, and attached is a patch to add the test. Peter, could
you merge it with 0001? I am fine to take care of that myself if
|Next Message||Michael Paquier||2019-01-08 04:02:00||Re: Displaying and dumping of table access methods|
|Previous Message||Andres Freund||2019-01-08 02:31:52||Re: Displaying and dumping of table access methods|