Re: Using PostgreSQL for service discovery and health-check

From: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
To: Dominique Devienne <ddevienne(at)gmail(dot)com>
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Using PostgreSQL for service discovery and health-check
Date: 2023-02-09 16:51:13
Message-ID: eea6ff37-a174-deac-11b4-8a590fedbdc9@aklaver.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 2/9/23 08:16, Dominique Devienne wrote:
> On Thu, Feb 9, 2023 at 5:05 PM Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com
> <mailto:adrian(dot)klaver(at)aklaver(dot)com>> wrote:
>

> Is there more then one server providing the same service?
>
>
> Yes. That was my PS: basically. The client can connect to any one, randomly.
> We need at least one of course. But there could me more than 1, yes.

> Would it no be easier to not have random ports and just attempt
> connections to the servers either:
> 1) In the client with reattempt to different port on failure.
> 2) From Postgres server and update table to have current up servers.
>
>
> I'm sorry, but I'm not following. Can you perhaps rephrase?
>
> Regarding ports, once you have registration of services, just seems
> easier to me to NOT have a fixed port,
> and let the host assign any port to the HTTP server. Those servers are
> not user-facing directly, from the client
> side, it calls an API and lookup of the service and connection to the
> HTTP server is transparent is an implementation
> detail, so the port used doesn't matter. In-DB registration of (HTTP)
> servers makes the while URL an implementation detail.

The flip side of that is that with known ports it would it easier to
have a process on the Postgres machine or in the database that checks
the ports on regular basis. And as part of that process mark any non
responding ports as inactive. That would solve the zombie problem.

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2023-02-09 16:59:48 Re: ERROR: posting list tuple with 2 items cannot be split at offset 17
Previous Message David G. Johnston 2023-02-09 16:37:29 Re: WHERE col = ANY($1) extended to 2 or more columns?