From: | Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Support for N synchronous standby servers |
Date: | 2014-08-22 10:14:36 |
Message-ID: | BF2827DCCE55594C8D7A8F7FFD3AB77158E2C3D4@SZXEML508-MBX.china.huawei.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 09 August 2014 11:33, Michael Paquier Wrote:
> Please find attached a patch to add support of synchronous replication
> for multiple standby servers. This is controlled by the addition of a
> new GUC parameter called synchronous_standby_num, that makes server
> wait for transaction commit on the first N standbys defined in
> synchronous_standby_names. The implementation is really straight-
> forward, and has just needed a couple of modifications in walsender.c
> for pg_stat_get_wal_senders and syncrep.c.
I have just started looking into this patch.
Please find below my first level of observation from the patch:
1. Allocation of memory for sync_nodes in function SyncRepGetSynchronousNodes should be equivalent to allowed_sync_nodes instead of max_wal_senders. As anyway we are not going to store sync stdbys more than allowed_sync_nodes.
sync_nodes = (int *) palloc(allowed_sync_nodes * sizeof(int));
2. Logic of deciding the highest priority one seems to be in-correct.
Assume, s_s_num = 3, s_s_names = 3,4,2,1
standby nodes are in order as: 1,2,3,4,5,6,7
As per the logic in patch, node 4 with priority 2 will not be added in the list whereas 1,2,3 will be added.
The problem is because priority updated for next tracking is not the highest priority as of that iteration, it is just priority of last node added to the list. So it may happen that a node with higher priority is still there in list but we are comparing with some other smaller priority.
3. Can we optimize the function SyncRepGetSynchronousNodes in such a way that it gets the number of standby nodes from s_s_names itself. With this it will be usful to stop scanning the moment we get first s_s_num potential standbys.
Thanks and Regards,
Kumar Rajeev Rastogi
From | Date | Subject | |
---|---|---|---|
Next Message | Jeevan Chalke | 2014-08-22 10:21:18 | Re: Re: proposal: ignore null fields in not relation type composite type based constructors |
Previous Message | Etsuro Fujita | 2014-08-22 09:38:23 | Re: inherit support for foreign tables |