Sean Chittenden <sean@chittenden.org> writes:
>> If you do that then I don't see what the advantage is. I thought
>> you meant this as a way of avoiding PID collisions after a reboot.
> It's a shared piece of information that can be used to determine if
> the postmaster is up and returning valid results if, at the protocol
> level, there was support for having the postmaster return the time at
> which it was started.
That seems unnecessary. All you'd really need is a "pg_ping" utility
that tries to open a connection to the postmaster, but doesn't bother
to go through with the connection request. If the socket connection
can be established then the database is presumably up. This could be
written today with no protocol change needed. I recall some prior
discussion about making pg_ping, but no one's got round to writing it.
It wouldn't necessarily be a bad idea to extend the protocol so that
such a utility could send an explicit "ping" packet rather than just
abandoning the connection, and the postmaster could answer back with
some simple status information like how long it's been up, whether it's
currently accepting connections, etc. But I don't think that pg_ctl has
to have that. You'd have to be pretty circumspect about how much status
you reveal to an unauthenticated caller, anyway.
regards, tom lane
