On Mon, 2008-09-15 at 09:07 -0400, Merlin Moncure wrote:
> > Well, my impression from all inputs is there is no single preferred
> > route. Any one of the approaches seems to have a possible objection,
> > depending upon the needs of the user. So I'm going to give options.
> >
> > In any case it's not just a two horse race. There are other options,
> > favoured by some people, that you've not personally commented on in
> any
> > of your summaries (thats up to you, of course).
> >
> > And "Standby causing master to bloat" is not such a big problem. It's no
> > different to running queries directly on the master. But please don't
> > take it that I don't see the problem or think it the best solution in
> > all cases.
>
> It's not a problem, but a relative disadvantage.
In some circumstances, yes, in others, not. But its not the only
consideration and different people attach different weightings in their
decision making.
> What makes warm
> standby really attractive relative to other data transfer solutions is
> that there are no side effects on the master outside of setting the
> archive command...communication is one way. Any 'master bloat' style
> approach seems to be increasingly fragile if you want to increase the
> number of standby servers, if it's even possible to do that.
>
> I'm not saying it should be the only way to do it (and it may not even
> be possible)...but it would be very attractive to be able to run a hot
> standby much the same as a warm standby is running today...I could,
> for example easily script a second standby but keep it a week behind
> for example.
I hope to provide options for all users, not just a single approach. If
you choose never to use the option to link standby and master, I respect
that and understand. I've listened to your requirements and believe I'm
including things to allow it to work for you the way you've said.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
