From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> |
Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Sync Rep Design |
Date: | 2011-01-01 14:15:45 |
Message-ID: | AANLkTi=U6xzMpsrFbZkjQHrSnR_n+M9iGLrx0p8a4n+j@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jan 1, 2011 at 9:03 AM, Stefan Kaltenbrunner
<stefan(at)kaltenbrunner(dot)cc> wrote:
> that is exactly my point - if have no guarantee that your SYNC standby is
> actually sync there is no use for it being used in business cases that
> require sync replication.
> If we cannot support that usecase I would either like to see us restricting
> to only one sync capable standby or by putting a big CAVEAT into the docs
> saying that sync replication in pg only is a hint and not a guarantee that
> might or might not be honored in the case of more than one standby.
I think it's clear that different people want to different things. I
understand Simon's point, but I think the point Stefan and Jeff are
making is equally valid. I think the solution is:
- Simon gets to implement his version first because he's writing the
code. If someone else writes the code then they get to pick.
- Whoever wants to make the other thing work can write a patch for that after.
- The docs should not allege that either setup is preferable to the
other, because there is not now and will never be consensus that this
is in fact true.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Guillaume Lelarge | 2011-01-01 14:53:57 | Re: and it's not a bunny rabbit, either |
Previous Message | Stefan Kaltenbrunner | 2011-01-01 14:03:35 | Re: Sync Rep Design |