Re: BUG #5118: start-status-insert-fatal - Mailing list pgsql-bugs

From Kevin Grittner
Subject Re: BUG #5118: start-status-insert-fatal
Date
Msg-id 4AD71D57020000250002B9E0@gw.wicourts.gov
Whole thread Raw
In response to Re: BUG #5118: start-status-insert-fatal  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: BUG #5118: start-status-insert-fatal
List pgsql-bugs
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> wrote:

> I neglected that point in my recently proposed LSB conforming script

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.

-Kevin

pgsql-bugs by date:

Previous
From: "Steven McLellan"
Date:
Subject: BUG #5120: Performance difference between running a query with named cursor and straight SELECT
Next
From: Tom Lane
Date:
Subject: Re: BUG #5118: start-status-insert-fatal