On Mon, Aug 11, 2014 at 11:54 AM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Mon, Aug 11, 2014 at 1:31 AM, Fujii Masao <masao.fu...@gmail.com> wrote: >> On Sat, Aug 9, 2014 at 3:03 PM, Michael Paquier >> <michael.paqu...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers