Was this ever addressed? ---------------------------------------------------------------------------
Tom Lane wrote: > "Kevin Grittner" <kevin.gritt...@wicourts.gov> writes: > > Tom Lane <t...@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 > > -- > Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
