From: | Maxim Orlov <orlovmg(at)gmail(dot)com> |
---|---|
To: | Jelte Fennema <Jelte(dot)Fennema(at)microsoft(dot)com> |
Cc: | Michael Banck <mbanck(at)gmx(dot)net>, Aleksander Alekseev <aleksander(at)timescale(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [EXTERNAL] Re: Support load balancing in libpq |
Date: | 2022-09-14 14:53:48 |
Message-ID: | CACG=ezYazYUj3TQVSPL-G5Bhea0hApTbknhAbCX=yNDdu=gpyw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
+1 for overall idea of load balancing via random host selection.
For the patch itself, I think it is better to use a more precise time
function in libpq_prng_init or call it only once.
Thought it is a special corner case, imagine all the connection attempts at
first second will be seeded with the save
value, i.e. will attempt to connect to the same host. I think, this is not
we want to achieve.
And the "hostroder" option should be free'd in freePGconn.
> Also, IMO, the solution must have a fallback mechanism if the
> standby/chosen host isn't reachable.
Yeah, I think it should. I'm not insisting on a particular name of options
here, but in my view, the overall idea may be next:
- we have two libpq's options: "load_balance_hosts" and "failover_timeout";
- the "load_balance_hosts" should be "sequential" or "random";
- the "failover_timeout" is a time period, within which, if connection to
the server is not established, we switch to the next address or host.
While writing this text, I start thinking that load balancing is a
combination of two parameters above.
> 3) Isn't it good to provide a way to test the patch?
Good idea too. I think, we should add tap test here.
--
Best regards,
Maxim Orlov.
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2022-09-14 15:17:26 | Re: Refactoring postgres_fdw/connection.c |
Previous Message | Daniel Gustafsson | 2022-09-14 14:37:58 | Re: pg_receivewal and SIGTERM |