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 7c5636b4-14ab-13e4-325a-7c2ddf3c1f1c@aklaver.com
Whole thread Raw
In response to Re: Using PostgreSQL for service discovery and health-check  (Dominique Devienne <ddevienne@gmail.com>)
List pgsql-general
On 2/9/23 09:40, Dominique Devienne wrote:
> On Thu, Feb 9, 2023 at 5:51 PM Adrian Klaver <adrian.klaver@aklaver.com 
> <mailto:adrian.klaver@aklaver.com>> wrote:
> 
>     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>
>     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.
> 
> 
> That's one possibility. But the "reaper" process could just as well scan 
> the service table,
> and probe those too. So again, I'm not sure what the fixed-port approach 
> gains me, beside
> perhaps the reaper not having to connect to PostgreSQL itself. I'm OK 
> with connecting.

As to fixed port and pulling vs services pushing, there is a security 
side. Not sure who controls the external services, but there is the 
chance that someone knowing they exist could inject their own version of 
a service/server. With random ports that makes that easier as you would 
not know what is canonical. With the pull process you have a 
verified(presumably) list  of servers and ports they listen on.

> 
> Thanks for the your input. Always good to have one's arguments 
> challenged by experts.

-- 
Adrian Klaver
adrian.klaver@aklaver.com




pgsql-general by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: Sequence vs UUID
Next
From: Georg Heiler
Date:
Subject: delta.io foreign data wrapper