On Mon, Aug 11, 2014 at 11:54 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Mon, Aug 11, 2014 at 1:31 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
>> On Sat, Aug 9, 2014 at 3:03 PM, Michael Paquier
>> <michael.paquier@gmail.com> wrote:
>> Great! This is really the feature which I really want.
>> Though I forgot why we missed this feature when
>> we had added the synchronous replication feature,
>> maybe it's worth reading the old discussion which
>> may suggest the potential problem of N sync standbys.
> Sure, I'll double check. Thanks for your comments.
>
>> I just tested this feature with synchronous_standby_num = 2.
>> I started up only one synchronous standby and ran
>> the write transaction. Then the transaction was successfully
>> completed, i.e., it didn't wait for two standbys. Probably
>> this is a bug of the patch.
>
> Oh OK, yes this is a bug of what I did. The number of standbys to wait
> for takes precedence on the number of standbys found in the list of
> active WAL senders. I changed the patch to take into account that
> behavior. So for example if you have only one sync standby connected,
> and synchronous_standby_num = 2, client waits indefinitely.
Thanks for updating the patch! Again I tested the feature and found something
wrong. I set synchronous_standby_num to 2 and started three standbys. Two of
them are included in synchronous_standby_names, i.e., they are synchronous
standbys. That is, the other one standby is always asynchronous. When
I shutdown one of synchronous standbys and executed the write transaction,
the transaction was successfully completed. So the transaction doesn't wait for
two sync standbys in that case. Probably this is a bug.
Regards,
--
Fujii Masao
