Re: [WIP] pg_ping utility

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Phil Sorber <phil(at)omniti(dot)com>
Cc: PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [WIP] pg_ping utility
Date: 2012-11-23 14:48:58
Message-ID: CAB7nPqSOruR3ds0TsU3P85_Huj7jQyVnDRq0giXn3iRxFMnQpQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Nov 17, 2012 at 2:48 AM, Phil Sorber <phil(at)omniti(dot)com> wrote:

> On Thu, Nov 15, 2012 at 10:55 PM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
> > On Fri, Nov 16, 2012 at 12:34 PM, Phil Sorber <phil(at)omniti(dot)com> wrote:
> >> On Thu, Nov 15, 2012 at 9:23 PM, Michael Paquier
> >> <michael(dot)paquier(at)gmail(dot)com> wrote:
> >> > 3) Having an output close to what ping actually does would also be
> nice,
> >> > the
> >> > current output like Accepting/Rejecting Connections are not that
> >>
> >> Could you be more specific? Are you saying you don't want to see
> >> accepting/rejecting info output?
> >
> > OK sorry.
> >
> > I meant something like that for an accessible server:
> > $ pg_ping -c 3 -h server.com
> > PING server.com (192.168.1.3)
> > accept from 192.168.1.3: icmp_seq=0 time=0.241 ms
> > accept from 192.168.1.3: icmp_seq=0 time=0.240 ms
> > accept from 192.168.1.3: icmp_seq=0 time=0.242 ms
> >
> > Like that for a rejected connection:
> > reject from 192.168.1.3: icmp_seq=0 time=0.241 ms
> >
> > Like that for a timeout:
> > timeout from 192.168.1.3: icmp_seq=0
> > Then print 1 line for each ping taken to stdout.
>
> How does icmp_seq fit into this? Or was that an oversight?
>
> Also, in standard ping if you don't pass -c it will continue to loop
> until interrupted. Would you suggest that pg_ping mimic that, or that
> we add an additional flag for that behavior?
>
> FWIW, I would use 'watch' with the existing output for cases that I
> would need something like that.
>
We waited a couple of days for feedback for this feature. So based on all
the comments provided by everybody on this thread, perhaps we should move
on and implement the options that would make pg_ping a better wrapper for
PQPing. Comments?
--
Michael Paquier
http://michael.otacoo.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2012-11-23 15:03:30 Re: Invalid optimization of VOLATILE function in WHERE clause?
Previous Message Henning Mälzer 2012-11-23 14:17:59 Question: Can i cut NON-HOT chain Pointers if there are no concurrent updates?