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.
> And, you forgot to add the line of synchronous_standby_num
> to postgresql.conf.sample.
Yep, right.
On top of that, I refactored the code in such a way that
pg_stat_get_wal_senders and SyncRepReleaseWaiters rely on a single API
to get the list of synchronous standbys found. This reduces code
duplication, duplication that already exists in HEAD...
Regards,
--
Michael
