Re: Sync Rep Design

On 31.12.2010 6:02, Robert Haas wrote:
> On Thu, Dec 30, 2010 at 8:57 PM, Simon Riggs<simon@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