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

From Tom Lane
Subject Re: BUG #5118: start-status-insert-fatal
Date
Msg-id 11911.1255632779@sss.pgh.pa.us
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> writes:
> Sounds good to me, other than it stalls pg_ctl revamp until pg_ping is
> done.  I don't remember a clear design of what pg_ping should look
> like.  Does anyone have a clear plan in their head?

I don't think anyone's written down a full spec, but it seems like a
relatively trivial thing to me.

* Client connects to the usual place and sends a packet that has a
special "protocol number" (similar to the way we handle SSL requests).
AFAICS there wouldn't need to be anything else in the packet.

* Postmaster responds with a suitable message and closes the connection.
The message should at least include the current postmaster
CanAcceptConnections status and the PID/magic number we were just
discussing.  I can't think of anything else offhand --- anyone else?

I'm not sure whether we'd want to provide a function within libpq
for this, or just code it in pg_ctl.  Within libpq the natural
thing would be to take a conninfo connection string, but I'm not
sure that suits pg_ctl's purposes.

            regards, tom lane

pgsql-bugs by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: BUG #5118: start-status-insert-fatal
Next
From: Tom Lane
Date:
Subject: Re: Postgresql 8.4.1 segfault, backtrace