Re: standby registration (was: is sync rep stalled?)
От | Simon Riggs |
---|---|
Тема | Re: standby registration (was: is sync rep stalled?) |
Дата | |
Msg-id | 1286289184.2025.1440.camel@ebony обсуждение исходный текст |
Ответ на | Re: standby registration (was: is sync rep stalled?) ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: standby registration (was: is sync rep stalled?)
Re: standby registration (was: is sync rep stalled?) Re: standby registration (was: is sync rep stalled?) |
Список | pgsql-hackers |
On Tue, 2010-10-05 at 09:07 -0500, Kevin Grittner wrote: > Simon Riggs <simon@2ndQuadrant.com> wrote: > > Robert Haas wrote: > >> Simon Riggs <simon@2ndquadrant.com> wrote: > >>> Josh Berkus wrote: > >>>>>>> Quorum commit, even with configurable vote weights, can't > >>>>>>> handle a requirement that a particular commit be replicated > >>>>>>> to (A || B) && (C || D). > >>>>>> Good point. > >>> > >>> Asking for quorum_commit = 3 would cover that requirement. > >>> > >>> Not exactly as requested, > > >> That's just not the same thing. > > > > In what important ways does it differ? > > When you have one server functioning at each site you'll block until > you get a third machine back, rather than replicating to both sites > and remaining functional. And that is so important a consideration that you would like to move from one parameter in one file to a whole set of parameters, set differently in 5 separate files? Is it a common use case that people have more than 3 separate servers for one application, which is where the difference shows itself. Another check: does specifying replication by server in such detail mean we can't specify robustness at the transaction level? If we gave up that feature, it would be a great loss for performance tuning. -- Simon Riggs www.2ndQuadrant.comPostgreSQL Development, 24x7 Support, Training and Services
В списке pgsql-hackers по дате отправления: