On 2014-02-21 19:03:29 +0530, Amit Kapila wrote:
> On Fri, Feb 21, 2014 at 2:36 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> > On 2014-02-21 10:08:44 +0530, Amit Kapila wrote:
> >>
> >> I think the main reason of ping is to detect n/w break sooner.
> >> On a busy server, wouldn't WALSender can detect it when next time it
> >> will try to send the remaining data?
> >
> > Well, especially on a pipelined connection, that can take a fair
> > bit. TCP timeouts aren't fun.
>
> Okay, but the behaviour should be same for both keepalive message
> and wal data it needs to send. What I mean to say here is that if n/w
> is down, wal sender will detect it early by sending some data (either
> keepalive or wal data). Also the ping is sent only after
> wal_sender_timeout/2 w.r.t last reply time and wal data will be
> sent after each sleeptime (1 + wal_sender_timeout/10) which
> I think is should be lesser than the time to send ping.
The danger is rather that *no* keepalive is sent (with requestReply =
true triggering a reply by the client) by the walsender. Try to run
pg_receivexlog against a busy server with a low walsender timeout. Since
we'll never get to sending a keepalive we'll not trigger a reply by the
receiver. Now
> > There's a reason we have the keepalives,
> > and that they measure application to application performance.
>
> Do you mean to say the info about receiver (uphill what it has
> flushed..)?
The important bit is updating walsender.c's last_reply_timestamp so we
know that the standby has updated and we won't kill it.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
