On Fri, Feb 21, 2014 at 7:10 PM, Andres Freund <andres@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 <andres@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
