Re: recovery_target_time and standby_mode - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: recovery_target_time and standby_mode
Date
Msg-id 545D41B7.20205@agliodbs.com
Whole thread Raw
In response to recovery_target_time and standby_mode  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
On 11/07/2014 01:30 PM, Robert Haas wrote:
> On Fri, Nov 7, 2014 at 4:00 PM, Josh Berkus <josh@agliodbs.com> wrote:
>> In order for this to work, the archive would need to stop before
>> recovery_target_time.
> 
> Yeah, good point.  I didn't think of the case where you've rewound the
> master but not the archive.  That will indeed require some special
> handling, but it also seems like a somewhat unusual setup, because if
> the master is trying to archive back to that same archive, archiving
> will fail, with all the usual problems that entails.  Or maybe the
> master is archiving there but on a different timeline, but in that
> case why can the standby follow the timeline switch when connecting
> directly to the master, but not via the archive?  My brain hurts.

I'm not surprised this issue hasn't come up before.  We manage
replication and archiving for many clients, and this is the first time
I've had this question.  The reason this user wants to do things this
way is that their archive storage is higher bandwidth (fiber) than their
local network, so it's faster to restore several servers in parallel
from the archive than it is to restore the master and then take basebackups.

But, like I said, there's a serviceable workaround.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: row_to_json bug with index only scans: empty keys!
Next
From: Atri Sharma
Date:
Subject: Re: Representing a SRF return column in catalogs