Skip site navigation (1) Skip section navigation (2)

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

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-bugs(at)postgresql(dot)org>, "Gerhard Leykam" <gel123(at)sealsystems(dot)de>
Subject: Re: BUG #5118: start-status-insert-fatal
Date: 2009-10-15 19:11:45
Message-ID: 4AD72DA1020000250002BA01@gw.wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-bugs
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.
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.
 
> 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?
 
-Kevin

In response to

Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2009-10-15 19:28:02
Subject: Re: BUG #5118: start-status-insert-fatal
Previous:From: Tom LaneDate: 2009-10-15 18:59:39
Subject: Re: BUG #5118: start-status-insert-fatal

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group