On 2014-02-21 19:03:29 +0530, Amit Kapila wrote: > On Fri, Feb 21, 2014 at 2:36 PM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers