From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | pgsql-bugs(at)postgresql(dot)org, "Gerhard Leykam" <gel123(at)sealsystems(dot)de> |
Subject: | Re: BUG #5118: start-status-insert-fatal |
Date: | 2009-10-15 18:15:11 |
Message-ID: | 11233.1255630511@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2009-10-15 18:21:12 | Re: BUG #5118: start-status-insert-fatal |
Previous Message | Kevin Grittner | 2009-10-15 18:02:13 | Re: BUG #5118: start-status-insert-fatal |