Re: Using PostgreSQL for service discovery and health-check - Mailing list pgsql-general

From Adrian Klaver
Subject Re: Using PostgreSQL for service discovery and health-check
Date
Msg-id eea6ff37-a174-deac-11b4-8a590fedbdc9@aklaver.com
Whole thread Raw
In response to Re: Using PostgreSQL for service discovery and health-check  (Dominique Devienne <ddevienne@gmail.com>)
Responses Re: Using PostgreSQL for service discovery and health-check
List pgsql-general
On 2/9/23 08:16, Dominique Devienne wrote:
> On Thu, Feb 9, 2023 at 5:05 PM Adrian Klaver <adrian.klaver@aklaver.com 
> <mailto:adrian.klaver@aklaver.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.klaver@aklaver.com




pgsql-general by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: WHERE col = ANY($1) extended to 2 or more columns?
Next
From: Adrian Klaver
Date:
Subject: Re: ERROR: posting list tuple with 2 items cannot be split at offset 17