Re: BUG #5118: start-status-insert-fatal

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #5118: start-status-insert-fatal
Дата
Msg-id 11233.1255630511@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #5118: start-status-insert-fatal  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Ответы Re: BUG #5118: start-status-insert-fatal  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: BUG #5118: start-status-insert-fatal  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Hmmm...  On review, I see that I assumed that the -w switch on pg_ctl
> start would cover this.  I see that the problem is that this uses psql
> to connect to the specified port.  Besides the problems Tom mentioned
> with its heuristics to find the right port number for this cluster,
> there is the OP's point that connections will go to the competing
> cluster.  One thought that occurs to me is that instead of, or in
> addition to, the new file Tom proposes, the "other cluster" issue
> could be solved by having a pg_postmaster_pid function in addition to
> the pg_backend_pid function.  This would allow pg_ctl or a script to
> connect to a port and see if it is the expected postmaster process.

I would rather see us implement the hypothetical pg_ping protocol
and remember to include the postmaster's PID in the response.  One
of the worst misfeatures of pg_ctl is the need to be able to
authenticate itself to the postmaster, and having it rely on being
able to actually issue a SQL command would set that breakage in stone.

            regards, tom lane

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

Предыдущее
От: "Kevin Grittner"
Дата:
Сообщение: Re: BUG #5118: start-status-insert-fatal
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Re: BUG #5118: start-status-insert-fatal