Re: [PATCH] Allow Postgres to pick an unused port to listen

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [PATCH] Allow Postgres to pick an unused port to listen
Дата
Msg-id CA+TgmobxUVJ9O6i_tYX9bFL4dO1UAKSgTnj1tGz0+c5MTRDLXA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] Allow Postgres to pick an unused port to listen  (Yurii Rashkovskii <yrashk@gmail.com>)
Ответы Re: [PATCH] Allow Postgres to pick an unused port to listen  (Yurii Rashkovskii <yrashk@gmail.com>)
Список pgsql-hackers
On Fri, Apr 7, 2023 at 5:34 PM Yurii Rashkovskii <yrashk@gmail.com> wrote:
> I'm trying to understand what's wrong with reading port from the pid file (if Postgres writes information there, it's
surelyso that somebody can read it, otherwise, why write it in the first placd)? The proposed solution uses operating
system'sfunctionality to achieve collision-free mechanics with none of the complexity introduced in the commit. 

I agree. We don't document the exact format of the postmaster.pid file
to my knowledge, but storage.sgml lists all the things it contains,
and runtime.sgml documents that the first line contains the postmaster
PID, so this is clearly not some totally opaque file that nobody
should ever touch. Consequently, I don't agree with Tom's statement
that this would be a "a horrid way to find out what was picked." There
is some question in my mind about whether this is a feature that we
want PostgreSQL to have, and if we do want it, there may be some room
for debate about how it's implemented, but I reject the idea that
extracting the port number from postmaster.pid is intrinsically a
terrible plan. It seems like a perfectly reasonable plan.

--
Robert Haas
EDB: http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: When to drop src/tools/msvc support
Следующее
От: Dave Page
Дата:
Сообщение: Re: When to drop src/tools/msvc support