Re: BUG #5118: start-status-insert-fatal

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-bugs(at)postgresql(dot)org, Gerhard Leykam <gel123(at)sealsystems(dot)de>
Subject: Re: BUG #5118: start-status-insert-fatal
Date: 2010-02-22 17:31:46
Message-ID: 201002221731.o1MHVkH19768@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs


Was this ever addressed?

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

Tom Lane wrote:
> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> > Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs

--
Bruce Momjian <bruce(at)momjian(dot)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. +

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Kevin Grittner 2010-02-22 17:46:09 Re: helo
Previous Message Kris Jurka 2010-02-22 17:25:29 Re: helo