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

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: David Steele <david(at)pgmasters(dot)net>, 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-13 09:17:32
Message-ID: 4a639766-4681-99d5-0e73-f2a93a63e7a1@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12/01/2019 00:53, Michael Paquier wrote:
> On Fri, Jan 11, 2019 at 11:17:48AM +0100, Peter Eisentraut wrote:
>> Attached revised 0002 with those changes.
>
> This one looks fine.

committed

>> In that test, if I change the 'current' to 'latest', the test doesn't
>> fail, so it's probably not a good test.
>
> I can see your point. You would need a diverging timeline to test for
> 'latest', which can surely be done as part of 003_recovery_targets.pl.
> It seems to me that that the test has initial value to make sure that
> we replay up to the end of the produced timeline's data, which is
> something untested now as the script has only restart points set to
> before the end of the timeline. If you think that's not a good
> addition now, I am also fine to not include it.

I'm not sure what the coverage is in detail in this area. It seems we
already have tests for not-specific-recovery-target, maybe not in this
file, but most of the other tests rely on that, no?

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2019-01-13 09:32:59 Re: Python versions (was Re: RHEL 8.0 build)
Previous Message Michael Paquier 2019-01-13 09:02:16 Re: O_DIRECT for relations and SLRUs (Prototype)