On Fri, Feb 21, 2014 at 7:10 PM, Andres Freund <and...@2ndquadrant.com> wrote: > 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: >> > 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
Looking at code of pg_receivexlog in function HandleCopyStream(), it seems that it can only happen if user has not configured --status-interval in pg_receivexlog. Code referred is as below: HandleCopyStream() { .. /* * Potentially send a status message to the master */ now = localGetCurrentTimestamp(); if (still_sending && standby_message_timeout > 0 && localTimestampDifferenceExceeds(last_status, now, standby_message_timeout)) { /* Time to send feedback! */ if (!sendFeedback(conn, blockpos, now, false)) goto error; last_status = now; } Even if this is not happening due to some reason, shouldn't this be anyway the responsibility of pg_receivexlog to send the status from time to time rather than sending when server asked for it? With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers