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. > 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..)? If yes, then won't we get this information in other reply message or sending keepalive will achieve any other purpose (may be it can get info more quickly)? > And > detecting systems as down is important for e.g. synchronous rep. If you are right, then I am missing some point which is how on a busy server sending keepalive can detect n/w break more quickly then current way. 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
