I am going to be unavailable until Wednesday, so maybe gives us a few
more days for feedback.
On Fri, Nov 23, 2012 at 9:48 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
>
>
> On Sat, Nov 17, 2012 at 2:48 AM, Phil Sorber <phil@omniti.com> wrote:
>>
>> On Thu, Nov 15, 2012 at 10:55 PM, Michael Paquier
>> <michael.paquier@gmail.com> wrote:
>> > On Fri, Nov 16, 2012 at 12:34 PM, Phil Sorber <phil@omniti.com> wrote:
>> >> On Thu, Nov 15, 2012 at 9:23 PM, Michael Paquier
>> >> <michael.paquier@gmail.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
