Re: Using PostgreSQL for service discovery and health-check
От | Adrian Klaver |
---|---|
Тема | Re: Using PostgreSQL for service discovery and health-check |
Дата | |
Msg-id | 7c5636b4-14ab-13e4-325a-7c2ddf3c1f1c@aklaver.com обсуждение исходный текст |
Ответ на | Re: Using PostgreSQL for service discovery and health-check (Dominique Devienne <ddevienne@gmail.com>) |
Список | 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 по дате отправления: