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
Re: BUG #5118: start-status-insert-fatal |
Список | 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 по дате отправления: