"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I'm not sure whether we'd want to provide a function within libpq
>> for this, or just code it in pg_ctl.
> I'm inclined to think there would be value to a pg_ping utility to
> support automated monitoring by unprivileged users on other boxes.
True. I had first thought that pg_ctl itself could serve that purpose,
but it's really designed around the assumption that it has direct access
to $PGDATA, so it wouldn't fit well for monitoring from another machine.
> That both suggests libpq as the location, and one or two additional
> pieces of information. An indication of "in archive recovery" versus
> production or shutdown, for example, might be useful. I'm not sure
> what else might make sense.
IIRC, that's already covered by the CanAcceptConnections state.
We need to be pretty conservative about how much information we
expose here, anyhow, since it will be handed out to absolutely
anybody who can reach the postmaster port.
>> Within libpq the natural thing would be to take a conninfo
>> connection string, but I'm not sure that suits pg_ctl's purposes.
> I'm a little lost on that. Would it cause any problems for pg_ctl,
> or just be more than it would need if it's only implemented there?
Well, given what we were saying about a postmaster.ports file, pg_ctl
would typically be working with an absolute path to the socket file.
Which is not what normally goes into a conninfo string. Perhaps that
could be addressed by specifying the file contents differently, but
I'd be wary of assuming that *all* users of the ports file will be
libpq-based --- for instance a Java version of pg_ctl wouldn't be.
regards, tom lane
