On 31.12.2010 6:02, Robert Haas wrote:
On Thu, Dec 30, 2010 at 8:57 PM, Simon Riggs<si...@2ndquadrant.com>  wrote:
I'm not very clear what your response has to do with Stefan's comments.

My general perspective is that MySQL released a simple design a year
ahead of us, which should be to our collective shame. I will be working
towards delivering something useful in this release.
I don't feel ashamed of our feature set and I am not out to beat MySQL
or anyone else, just to deliver the best product that we can.
The key word here is "deliver" . The aim is to "deliver" sync rep, not "specify, leaving out controversial details". The registration part has been left out for a reason - while the registration itself is easy, deciding all the interactions with already running replication is not. Doing just the minimal support for sync rep (need acknowledge from at least one standby) and leaving the management of standbys to user enables us to get to actual
working code instead of a pie-in-the-sky wishlist.

  Our
community has different interests than the MySQL community and that is
fine.  Still, I don't disagree that we should be aiming at feature
parity.

<reads MySQL documentation>

I see now that you've tried to design this feature in a way that is
similar to MySQL's offering, which does have some value.  But it
appears to me that the documentation you've written here is
substantially similar to the MySQL 5.5 reference documentation.  That
could get us into a world of legal trouble - that documentation is not
even open source, let alone BSD.

http://dev.mysql.com/doc/refman/5.5/en/replication-semisync.html
Maybe we should get someone who has not read mysql docs to re-write a spec in a
"clean room" fashion, by just inspecting code and asking Simon et.al.

I would rather concentrate on a minimal set of functionality that we can
all agree on.
Me too; and perhaps your proposal is it.  But I think it's a shame we
didn't put more work into standby registration when we had time to get
that done.
When you need _just_ the registration, then make a table and two functions
pg_standby_register(name) and pg_standby_unregister(name)
For a little more added functionality add a third one pg_standby_last_seen(name) to update last seen timestamp and a script that polls all standbys and calls this.
   It might not be necessary, but it would have delivered
some nice functionality that we are now not going to have for 9.1.
There are tons of "nice functionality we are not going to have for 9.1", lets just not
make this cause even more nice functionality being left out !

---------------------
Hannu Krosing


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to