Re: Configuring synchronous replication
Fujii Masao <masao.fujii@gmail.com>
From: Fujii Masao <masao.fujii@gmail.com>
To: Dimitri Fontaine <dfontaine@hi-media.com>
Cc: Simon Riggs <simon@2ndquadrant.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-21T07:58:25Z
Lists: pgsql-hackers
On Sat, Sep 18, 2010 at 4:36 AM, Dimitri Fontaine <dfontaine@hi-media.com> wrote: > 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. Yep, I can imagine that some people want to ensure that *all* the transactions are synchronously replicated to the synchronous standby, without regard to sync_replication. So I'm not sure if automatic downgrade/upgrade of the mode makes sense. We should introduce new parameter specifying whether to allow automatic degrade/upgrade or not? It seems complicated though. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center