On 08/01/2019 04:37, Michael Paquier wrote:
> On Mon, Dec 31, 2018 at 01:21:00PM +0200, David Steele wrote:
>> This patch looks good to me.
>
> 0001 looks fine to me.
committed that one
> - 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?
>
> - 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.
Attached revised 0002 with those changes.
>> 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.
In that test, if I change the 'current' to 'latest', the test doesn't
fail, so it's probably not a good test.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
