Re: Support for N synchronous standby servers

On Fri, Aug 15, 2014 at 8:28 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> Now that we discuss the interactions with other parameters. Another
>> thing that I am wondering about now is: what should we do if we
>> specify s_s_num to a number higher than the elements in s_s_names?
>> Currently, the patch gives the priority to s_s_num, in short if we set
>> s_s_num to 100, server will wait for 100 servers to confirm commit
>> even if there are less than 100 elements in s_s_names. I chose this
>> way because it looks saner particularly if s_s_names = '*'. Thoughts
>> once again?
>
> I'm fine with this. As you gave an example, the number of entries in s_s_names
> can be smaller than the number of actual active sync standbys. For example,
> when s_s_names is set to 'hoge', more than one standbys with the name 'hoge'
> can connect to the server with sync mode.

This is a bit tricky. Suppose there is one standby connected which
has reached the relevant WAL position. We then lose that connection,
and a new standby connects. When or if the second standby is known to
have reached the relevant WAL position, can we release waiters? It
depends. If the old and new connections are to two different standbys
that happen to have the same name, yes. But if it's the same standby
reconnecting, then no.

> I still think that it's strange that replication can be async even when
> s_s_num is larger than zero. That is, I think that the transaction must
> wait for s_s_num sync standbys whether s_s_names is empty or not.

+1.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company