Re: Sync Rep v19
От | Robert Haas |
---|---|
Тема | Re: Sync Rep v19 |
Дата | |
Msg-id | AANLkTi=AuKLJCSD7TcTHiO-JqseR1ybJM4KZ8H_LNFxg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Sync Rep v19 (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Sync Rep v19
|
Список | pgsql-hackers |
On Sat, Mar 5, 2011 at 7:49 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > On Sat, 2011-03-05 at 07:24 -0500, Robert Haas wrote: >> On Sat, Mar 5, 2011 at 6:04 AM, Simon Riggs <simon@2ndquadrant.com> wrote: >> > It is documented that the selection of standby from a set of similar >> > priorities is indeterminate. Users don't like it, they can change it. >> >> That doesn't seem like a good argument to *change* the synchronous >> standby once it's already set. > > If the order is arbitrary, why does it matter if it changes? > > The user has the power to specify a sequence, yet they have not done so. > They are told the results are indeterminate, which is accurate. I can > add the words "and may change as new standbys connect" if that helps. I just don't think that's very useful behavior. Suppose I have a master and two standbys. Both are local (or both are remote with equally good connectivity). When one of the standbys goes down, there will be a hiccup (i.e. transactions will block trying to commit) until that guy falls off and the other one takes over. Now, when he comes back up again, I don't want the synchronous standby to change again; that seems like a recipe for another hiccup. I think "who the current synchronous standby is" should act as a tiebreak. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: