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

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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:02:13
Message-ID: 4AD71D57020000250002B9E0@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2009-10-15 18:15:11 Re: BUG #5118: start-status-insert-fatal
Previous Message Steven McLellan 2009-10-15 17:50:23 BUG #5120: Performance difference between running a query with named cursor and straight SELECT