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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
