Re: recovery_target_time and standby_mode - Mailing list pgsql-hackers

From Robert Haas
Subject Re: recovery_target_time and standby_mode
Date
Msg-id CA+TgmobsvU-sMrDp6=wxROPemvPvXdscJftppR2E9SuPsydQWg@mail.gmail.com
Whole thread Raw
In response to Re: recovery_target_time and standby_mode  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
On Fri, Nov 7, 2014 at 1:35 PM, Josh Berkus <josh@agliodbs.com> wrote:
> On 11/07/2014 08:12 AM, Robert Haas wrote:
>> On Wed, Nov 5, 2014 at 9:15 PM, Josh Berkus <josh@agliodbs.com> wrote:
>>> What I'm pointing out is that you can't actually do that.  You think you
>>> can, but you can't.
>>
>> I do think that.  You haven't explained why I'm wrong; just asserted
>> than I am.  Which doesn't really get us anywhere.
>
> TIAS.  I've already posted the steps I took and the result.  You're
> asserting that I'm wrong without even testing it.

You posted the steps you originally took; namely, setting
recovery_target_time = 'SOME-PAST-TIMESTAMP' and standby_mode = 'on'.
Several people then suggested that you could accomplish your
originally stated goal - namely "restore a master *and replica* to a
point in time before Bad Stuff happened, and then have a working
master-replica pair" - by just connecting the new standby to the
master directly, without using recovery_target_time.  As long as
primary_conninfo and restore_command are both set, the standby should
be able to fetch older segments from the archive and then seamlessly
switch to fetching new segments from the new master.  If you tried
that and it didn't work, I don't see a description of the outcome
anywhere on this thread.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: BRIN indexes - TRAP: BadArgument
Next
From: Robert Haas
Date:
Subject: Re: recovery_target_time and standby_mode