On Tue, 2010-09-21 at 16:58 +0900, Fujii Masao wrote: > On Sat, Sep 18, 2010 at 4:36 AM, Dimitri Fontaine > <dfonta...@hi-media.com> wrote: > > Simon Riggs <si...@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.
Hmm, no reason? The reason is that the alternative is that the session would hang until a standby arrived that offered that level of service. Why would you want that behaviour? Would you really request that option? > 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. I agree, but I'm not against any additional parameter if people say they really want them *after* the consequences of those choices have been highlighted. IMHO we should focus on the parameters that deliver key use cases. -- 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
