Re: Configuring synchronous replication
Dimitri Fontaine <dfontaine@hi-media.com>
From: Dimitri Fontaine <dfontaine@hi-media.com>
To: Simon Riggs <simon@2ndQuadrant.com>
Cc: Fujii Masao <masao.fujii@gmail.com>, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, Robert Haas <robertmhaas@gmail.com>, David Fetter <david@fetter.org>, Heikki Linnakangas <heikki@postgresql.org>, pgsql-hackers@postgresql.org
Date: 2010-09-17T19:36:32Z
Lists: pgsql-hackers
Simon Riggs <simon@2ndQuadrant.com> writes: > On Fri, 2010-09-17 at 21:20 +0900, Fujii Masao wrote: >> What synchronization level does each combination of sync_replication >> and sync_replication_service lead to? > > There are only 4 possible outcomes. There is no combination, so we don't > need a table like that above. > > The "service" specifies the highest request type available from that > specific standby. If someone requests a higher service than is currently > offered by this standby, they will either > a) get that service from another standby that does offer that level > b) automatically downgrade the sync rep mode to the highest available. I like the a) part, I can't say the same about the b) part. There's no reason to accept to COMMIT a transaction when the requested durability is known not to have been reached, unless the user said so. > For example, if you request recv but there is only one standby and it > only offers async, then you get downgraded to async. If so you choose, but with a net slowdown as you're now reaching the timeout for each transaction, with what I have in mind, and I don't see how you can avoid that. Even if you setup the replication from the master, you still can mess it up the same way, right? Regards, -- dim