Postgres Pro
Downloads
Home   >   mailing lists

Re: Patch: Implement failover on libpq connect level. - Mailing list pgsql-hackers

From Mithun Cy
Subject Re: Patch: Implement failover on libpq connect level.
Date
Msg-id CAD__Ouj+Wwmsv0hGEhUqNg+7mmpZYkbF4TFWnGMqnd97N9bqkQ@mail.gmail.com
Whole thread Raw
In response to Re: Patch: Implement failover on libpq connect level.  (Victor Wagner <vitus@wagner.pp.ru>)
Responses Re: Patch: Implement failover on libpq connect level.
List pgsql-hackers
Tree view
This patch do not apply on latest code. it fails as follows
libpq-failover-9.patch:176: trailing whitespace.
thread.o pgsleep.o
libpq-failover-9.patch:184: trailing whitespace.
check: 
libpq-failover-9.patch:185: trailing whitespace.
$(prove_check)
libpq-failover-9.patch:186: trailing whitespace.

libpq-failover-9.patch:194: trailing whitespace.
rm -rf tmp_check
error: patch failed: doc/src/sgml/libpq.sgml:792
error: doc/src/sgml/libpq.sgml: patch does not apply
error: patch failed: src/interfaces/libpq/Makefile:36
error: src/interfaces/libpq/Makefile: patch does not apply
error: patch failed: src/interfaces/libpq/fe-connect.c:299
error: src/interfaces/libpq/fe-connect.c: patch does not apply
error: patch failed: src/interfaces/libpq/libpq-fe.h:62
error: src/interfaces/libpq/libpq-fe.h: patch does not apply
error: patch failed: src/interfaces/libpq/libpq-int.h:334
error: src/interfaces/libpq/libpq-int.h: patch does not apply
error: patch failed: src/interfaces/libpq/test/expected.out:1
error: src/interfaces/libpq/test/expected.out: patch does not apply
error: patch failed: src/test/perl/PostgresNode.pm:398
error: src/test/perl/PostgresNode.pm: patch does not apply


On Tue, Sep 27, 2016 at 2:49 PM, Victor Wagner <vitus@wagner.pp.ru> wrote:
1).
>* if there is more than one host in the connect string and
>* target_server_type is not specified explicitely, set
>* target_server_type to "master", because default mode of
>* operation is failover, and so, we need to connect to RW
>* host, and keep other nodes of the cluster in the connect
>* string just in case master would fail and one of standbys
>* would be promoted to master.

I am slightly confused. As per this target_server_type=master means user is expecting failover. What if user pass target_server_type=any and request sequential connection isn't this also a case for failover?.  I think by default it should be "any" for any number of hosts. And parameter "sequential and random will decide whether we want just failover or with load-balance.

2).

>For some reason DNS resolving was concentrated in one place before my
>changes. So, I've tried to not change this decision.

My intention was not to have a replacement function for "pg_getaddrinfo_all", I just suggested to

have a local function which call pg_getaddrinfo_all for every host, port pair read earlier. By this way we need not to maintain nodes struct. This also reduces complexity of connectDBStart.

FUNC (host, port, addrs)

{

    CALL pg_getaddrinfo_all(host, port, newaddrs);

   addrs-> ai_next = newaddrs;

}

3).

I think you should run a spellcheck once. And, there are some formatting issue with respect to comments and curly braces of controlled blocks which need to be fixed.

--
Thanks and Regards
Mithun C Y

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Let file_fdw access COPY FROM PROGRAM
Next
From: Heikki Linnakangas
Date:
Subject: Re: PL/Python adding support for multi-dimensional arrays