"Joshua D. Drake" <jd@commandprompt.com> writes:
> On 01/08/2014 01:55 PM, Tom Lane wrote:
>> Sync mode is about providing a guarantee that the data exists on more than
>> one server *before* we tell the client it's committed. If you don't need
>> that guarantee, you shouldn't be using sync mode. If you do need it,
>> it's not clear to me why you'd suddenly not need it the moment the going
>> actually gets tough.
> As I understand it what is being suggested is that if a subscriber or
> target goes down, then the master will just sit there and wait. When I
> read that, I read that the master will no longer process write
> transactions. If I am wrong in that understanding then cool. If I am not
> then that is a serious problem with a production scenario. There is an
> expectation that a master will continue to function if the target is
> down, synchronous or not.
Then you don't understand the point of sync mode, and you shouldn't be
using it. The point is *exactly* to refuse to commit transactions unless
we can guarantee the data's been replicated.
There might be other interpretations of "synchronous replication" in which
it makes sense to continue accepting transactions whether or not there are
any up-to-date replicas; but in the meaning Postgres ascribes to the term,
it does not make sense. You should just use async mode if that behavior
is what you want.
Possibly we need to rename "synchronous replication", or document it
better. And I don't have any objection in principle to developing
additional replication modes that offer different sets of guarantees and
performance tradeoffs. But for the synchronous mode that we've got, the
proposed switch is insane, and asking for it merely proves that you don't
understand the difference between async and sync modes.
regards, tom lane