On Thu, Nov 13, 2014 at 2:45 AM, Josh Berkus wrote:
> On 11/12/2014 10:06 AM, Robert Haas wrote:
>>> hat *appears* to be happening is that the pause_at_recovery_target,
>>> > followed by the restart, on the replica causes it to advance one commit
>>> > on timeline 1. But *not all the time*; this
On 11/12/2014 10:06 AM, Robert Haas wrote:
>> hat *appears* to be happening is that the pause_at_recovery_target,
>> > followed by the restart, on the replica causes it to advance one commit
>> > on timeline 1. But *not all the time*; this doesn't happen in my
>> > pgbench-based tests.
>> >
>> > T
On Wed, Nov 12, 2014 at 12:12 PM, Josh Berkus wrote:
> On 11/07/2014 02:03 PM, Josh Berkus wrote:
>> But, like I said, there's a serviceable workaround.
>
> Some update on this. We've seen a problem in production with this setup
> which I can't reproduce as a test case, but which may jog Heikki's
On 11/07/2014 02:03 PM, Josh Berkus wrote:
> But, like I said, there's a serviceable workaround.
Some update on this. We've seen a problem in production with this setup
which I can't reproduce as a test case, but which may jog Heikki's
memory for something to fix.
1. Recover master to 2014-11-10
On 11/07/2014 01:30 PM, Robert Haas wrote:
> On Fri, Nov 7, 2014 at 4:00 PM, Josh Berkus 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. Th
On Fri, Nov 7, 2014 at 4:00 PM, Josh Berkus wrote:
> On 11/07/2014 12:02 PM, Robert Haas wrote:
>> 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 workin
On 11/07/2014 12:02 PM, Robert Haas wrote:
> 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 sta
On Fri, Nov 7, 2014 at 1:40 PM, Josh Berkus wrote:
> Is the current interaction of recovery_target_time and standby_mode
> (that is, that recovery_target_time causes standby_mode to be ignorned)
> the correct behavior?
I think this summary of the behavior is probably not correct in
detail. For e
On Fri, Nov 7, 2014 at 1:35 PM, Josh Berkus wrote:
> On 11/07/2014 08:12 AM, Robert Haas wrote:
>> On Wed, Nov 5, 2014 at 9:15 PM, Josh Berkus 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
All,
The point of this thread was to determine:
Is the current interaction of recovery_target_time and standby_mode
(that is, that recovery_target_time causes standby_mode to be ignorned)
the correct behavior?
If Yes, then we have a tech bug and a doc bug:
Tech Bug: if the user sets both recover
On 11/07/2014 08:12 AM, Robert Haas wrote:
> On Wed, Nov 5, 2014 at 9:15 PM, Josh Berkus 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 r
On Wed, Nov 5, 2014 at 9:15 PM, Josh Berkus 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.
However, if you do happen to
On 11/05/2014 05:41 PM, Michael Paquier wrote:
> On Thu, Nov 6, 2014 at 10:00 AM, Greg Stark wrote:
>> On Thu, Nov 6, 2014 at 12:32 AM, Josh Berkus wrote:
>>> When the recovery_target_time is reached, switch to streaming
>>> replication and stay a standby.
>>
>> Then shouldn't he just not specify
On Thu, Nov 6, 2014 at 10:41 AM, Michael Paquier
wrote:
> On Thu, Nov 6, 2014 at 10:00 AM, Greg Stark wrote:
>> On Thu, Nov 6, 2014 at 12:32 AM, Josh Berkus wrote:
>>> When the recovery_target_time is reached, switch to streaming
>>> replication and stay a standby.
>>
>> Then shouldn't he just n
On Thu, Nov 6, 2014 at 10:00 AM, Greg Stark wrote:
> On Thu, Nov 6, 2014 at 12:32 AM, Josh Berkus wrote:
>> When the recovery_target_time is reached, switch to streaming
>> replication and stay a standby.
>
> Then shouldn't he just not specify a recovert_target at all? That's
> the default behavi
On 11/05/2014 05:00 PM, Greg Stark wrote:
> On Thu, Nov 6, 2014 at 12:32 AM, Josh Berkus wrote:
>> When the recovery_target_time is reached, switch to streaming
>> replication and stay a standby.
>
> Then shouldn't he just not specify a recovert_target at all? That's
> the default behaviour for s
On Thu, Nov 6, 2014 at 12:32 AM, Josh Berkus wrote:
> When the recovery_target_time is reached, switch to streaming
> replication and stay a standby.
Then shouldn't he just not specify a recovert_target at all? That's
the default behaviour for standby_mode on, the whole point of
recovery_target i
17 matches
Mail list logo
