Re: hostorder and failover_timeout for libpq

From: Ildar Musin <ildar(at)adeven(dot)com>
To: surafel3000(at)gmail(dot)com
Cc: i(dot)musin(at)postgrespro(dot)ru, pgsql-hackers(at)postgresql(dot)org, v(dot)wagner(at)postgrespro(dot)ru
Subject: Re: hostorder and failover_timeout for libpq
Date: 2018-09-19 12:26:53
Message-ID: CAONYFtPL=v8M=rfc3MwE8gF1zwfQEUAa21qXVJFutFs3Oe0ksA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello Surafel,

On Fri, Sep 14, 2018 at 2:03 PM Surafel Temesgen <surafel3000(at)gmail(dot)com>
wrote:

> Hey ,
> Here are a few comment.
> + <varlistentry id="libpq-connect-falover-timeout"
> xreflabel="failover_timeout">
> Here's a typo: ="libpq-connect-falover-timeout"
> + {"failover_timeout", NULL, NULL, NULL,
> + "Failover Timeout", "", 10,
> Word is separated by hyphen in internalPQconninfoOption lable as a
> surrounding code
> + If the value is <literal>random</literal>, the host to connect to
> + will be randomly picked from the list. It allows load balacing
> between
> + several cluster nodes.
> I Can’t think of use case where randomly picking a node rather than in
> user specified order can load balance the cluster better. Can you
> explain the purpose of this feature more?

Probably load-balancing is a wrong word for this. Think of it as a
connection routing mechanism. Let's say you have 10 servers and 100 clients
willing to establish read-only connection. Without this feature all clients
will go to the first specified host (unless they hit max_connections
limit). And with random `hostorder` they would be splited between hosts
more or less evenly.

> And in the code I can’t see
> a mechanism for preventing picking one host multiple time
>
The original idea was to collect all ip addresses that we get after
resolving specified hostnames, put those addresses into a global array,
apply random permutations to it and then use round robin algorithm trying
to connect to each of them until we succeed. Now I'm not sure that this
approach was the best. There are two concerns:

1. host name can be resolved to several ip addresses (which in turn can
point to either the same physical server with multiple network interfaces
or different servers). In described above schema each ip address would be
added to the global array. This may lead to a situation when one host gets
higher chance of being picked because it has more addresses in global array
than other hosts.
2. host may support both ipv4 and ipv6 connections, which again leads to
extra items in global array and therefore also increases its chance to be
picked.

Another approach would be to leave `pg_conn->connhost` as it is now (i.e.
not to create global addresses array) and just apply random permutations to
it if `hostorder=random` is specified. And probably apply permutations to
addresses list within each individual host.

At this point I'd like to ask community what in your opinion would be the
best course of action and whether this feature should be implemented within
libpq at all? Because from my POV there are factors that really depend on
network architecture and there is probably no single right solution.

Kind regards,
Ildar

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Arthur Zakirov 2018-09-19 12:53:25 Re: [HACKERS] proposal: schema variables
Previous Message Pavel Stehule 2018-09-19 12:08:04 Re: [HACKERS] proposal: schema variables