Received: from maia.hub.org (maia-2.hub.org [200.46.204.251])
	by mail.postgresql.org (Postfix) with ESMTP id 5313B1337B8D
	for <pgsql-hackers-postgresql.org@mail.postgresql.org>;
	Fri, 31 Dec 2010 03:52:51 -0400 (AST)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia,
	port 10024) with ESMTP id 87536-03-4
	for <pgsql-hackers-postgresql.org@mail.postgresql.org>;
	Fri, 31 Dec 2010 07:52:43 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10])
	by mail.postgresql.org (Postfix) with ESMTP id 548F11337B96
	for <pgsql-hackers@postgresql.org>;
	Fri, 31 Dec 2010 03:52:43 -0400 (AST)
Received: from [192.168.0.101] ([90.169.156.240])
	by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis)
	id 0LjdQ8-1Q5QYe2ZbM-00baT1; Fri, 31 Dec 2010 08:52:42 +0100
Message-ID: <4D1D8B53.7000108@2ndquadrant.com>
Date: Fri, 31 Dec 2010 08:50:43 +0100
From: Hannu Krosing <hannu@2ndquadrant.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
	rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: Robert Haas <robertmhaas@gmail.com>
CC: Simon Riggs <simon@2ndquadrant.com>, pgsql-hackers@postgresql.org
Subject: Re: Sync Rep Design
References: <1293729972.1892.23804.camel@ebony>
	<4D1CC47E.7050207@kaltenbrunner.cc>	<1293735853.1892.24886.camel@ebony>
	<4D1CEEAF.8050209@kaltenbrunner.cc>
	<AANLkTi=rGTp59iB5Qpf0ymwzn31F0oVOVuVCR_TAMPi5@mail.gmail.com>
	<1293760654.1892.29635.camel@ebony>
	<AANLkTi=59VVrA8-LfhRw0V8NAaxp4rP+6HnU+S91fxJb@mail.gmail.com>
In-Reply-To: <AANLkTi=59VVrA8-LfhRw0V8NAaxp4rP+6HnU+S91fxJb@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V02:K0:FNUBC+muahvC+3AhSSK4XGmHcbdr8lRTK8PkgXtVVt9
	nbLYURiSXJgI5t90RqhuVeeizsLXXg+3KoNkF41tN8co92E5H+
	mUR42v0tYWrWMWIRcj6T+4+hfeAs+e0zcLLda00RcGZHmcCstc
	1b+o15LIvHW20RkiesTyNuokKSvAearWFVGuDuDsyKSSiJ65Jo
	bhBgvdKe630OMDD/371SU9oFnH//RlXLmPXysG8MTA=
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-1.13 tagged_above=-5 required=5 tests=BAYES_00=-1.9,
	RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77
X-Spam-Level: 
X-Archive-Number: 201012/2534
X-Sequence-Number: 177796

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