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