> >> 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.
Agreed, that's why I figured the time at which the database was
started would be sufficient and wouldn't be constitute anything of
much value (could very well just be 4 encoded random bytes for all I
care, just needs to be a bit of shared info) given that some TCP
implimentations contain that in all IP packets.
I've added the pg_ping util to my todo list, but I'm swamped atm. Are
there any request bits that could be used for interactivity with the
server beyond the server being able to accept a connection?
-sc
--
Sean Chittenden