Re: Sync Rep v19
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Fujii Masao <masao.fujii@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
Date: 2011-03-05T13:05:31Z
Lists: 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