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

From Bruce Momjian
Subject Re: BUG #5118: start-status-insert-fatal
Date
Msg-id 201002221731.o1MHVkH19768@momjian.us
Whole thread Raw
In response to Re: BUG #5118: start-status-insert-fatal  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #5118: start-status-insert-fatal  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-bugs
Was this ever addressed?

---------------------------------------------------------------------------

Tom Lane wrote:
> "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
>
> --
> 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  <bruce@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. +

pgsql-bugs by date:

Previous
From: Kris Jurka
Date:
Subject: Re: helo
Next
From: "Kevin Grittner"
Date:
Subject: Re: helo