On Fri, Nov 18, 2016 at 6:39 AM, Tsunakawa, Takayuki < tsunakawa.ta...@jp.fujitsu.com> wrote: >Typo. <literaL. -> <literal>, and "observering" -> "observing".
Thanks fixed.
> + {"target_server_type", "PGTARGETSERVERTYPE",
DefaultTargetServerType, NULL,
> + "Target-Server-Type", "", 6,
Thanks fixed.
> Please avoid adding another round trip by using a GUC_REPORTed variable
(ParameterStatus entry). If you want to support this libpq failover with
>pre-10 servers, you can switch the method of determining the primary based
on the server version. But I don't think it's worth supporting older
servers > at the price of libpq code complexity.
Currently there is no consensus around this. For now, making this patch to
address failover to next primary as similar to JDBC seems sufficient for me.
On next proposal of patch I think we can try to extend as you have proposed
>Please consider supporting "standby" and "prefer_standby" like PgJDBC.
They are useful without load balancing when multiple standbys are used for
HA.
I think they become more relevant with load-balancing. And, making it
usable when we extend this feature to have load-balancing makes sense to
me.
> I haven't tracked the progress of logical replication, but will
target_server_type be likely to be usable with it? How will
target_server_type fit logical > replication?
I tried to check logical replication WIP patch, not very sure how to
accomodate same.
--
Thanks and Regards
Mithun C Y
EnterpriseDB: http://www.enterprisedb.com
failover_to_new_master_v3.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
