Re: could recovery_target_timeline=latest be the default in standby mode?

From: David Steele <david(at)pgmasters(dot)net>
To: Michael Paquier <michael(at)paquier(dot)xyz>
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?
Date: 2019-01-08 06:15:10
Message-ID: b001a65d-7d34-913b-adb5-cdf2b94851a6@pgmasters.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 1/8/19 5:37 AM, Michael Paquier wrote:
>
> - 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.
> + </para>
> Isn't it useful to still mention that the default is useful especially
> for standby servers?

Agreed.

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

Agreed.

>
>> 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
> necessary.

The new test looks good.

Regards,
--
-David
david(at)pgmasters(dot)net

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2019-01-08 06:30:10 Re: speeding up planning with partitions
Previous Message Tom Lane 2019-01-08 06:14:33 OpenBSD versus semaphores