Re: Configuring synchronous replication - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Configuring synchronous replication
Date
Msg-id m239t86u2n.fsf@hi-media.com
Whole thread Raw
In response to Re: Configuring synchronous replication  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Configuring synchronous replication  (Fujii Masao <masao.fujii@gmail.com>)
List 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


pgsql-hackers by date:

Previous
From: Dimitri Fontaine
Date:
Subject: Re: Configuring synchronous replication
Next
From: Bruce Momjian
Date:
Subject: Update comment for README.HOT