From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org>, Heikki Linnakangas <heikki(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Configuring synchronous replication |
Date: | 2010-09-17 16:00:29 |
Message-ID: | 1284739229.1733.5104.camel@ebony |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On Fri, 2010-09-17 at 16:09 +0300, Heikki Linnakangas wrote:
> >> I don't expect any meaningful differences in terms of performance
> >> between any of the discussed options. The big question right now is...
> >
> > This is the critical point. Politely, I would observe that *You* do not
> > think there is a meaningful difference. *I* do, and evidence suggests
> > that both Oracle and DRBD think so too. So we differ on what the "big
> > question" is here.
>
> We must be talking about different things again. There's certainly big
> differences in the different synchronization levels and configurations,
> but I don't expect there to be big performance differences between
> patches to implement those levels. Once we got rid of the polling loops,
> I expect the network and disk latencies to dominate.
So IIUC you seem to agree with
* 4 levels of synchronous replication (specified on master)
* transaction-controlled replication from the master
* sending 3 LSN values back from standby
Well, then that pretty much is my patch, except for the parameter UI.
Did I misunderstand?
We also agree that we need a standby to master protocol change; I used
Zoltan's directly and I've had zero problems with it in testing.
The only disagreement has been about
* the need for standby registration (I understand "want")
which seems to boil down to whether we wait for servers that *ought* to
be there, but currently aren't.
* whether to have wal writer active (I'm happy to add that later in this
release, so we get the "recv" option also)
* whether we have a parameter for quorum commit > 1 (happy to add later)
Not sure if there is debate about whether quorum_commit = 1 is the
default.
* whether we provide replication_exceptions as core feature or as a
plugin
The only area of doubt is when we send replies, which you haven't
thought about yet. So presumably you've no design-level objection to
what I've proposed.
Things we all seem to like are
* different standbys can offer different sync levels
* standby names
* a set returning function which tells you current LSNs of all standbys
* the rough idea of being able to specify a "service" and have that
equate to a more complex config underneath the covers, without needing
to have the application know the details - I think we need more details
on that before we could say "we agree".
So seems like a good days work.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Training and Services
From | Date | Subject | |
---|---|---|---|
Next Message | Jesper Krogh | 2010-09-17 16:24:51 | Re: Configuring synchronous replication |
Previous Message | Simon Riggs | 2010-09-17 15:49:44 | Re: Configuring synchronous replication |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2010-09-17 16:01:18 | Re: Report: removing the inconsistencies in our CVS->git conversion |
Previous Message | Robert Haas | 2010-09-17 15:55:41 | Re: Report: removing the inconsistencies in our CVS->git conversion |