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.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
