On Sun, Jun 20, 2010 at 10:41 PM, Florian Pflug <f...@phlo.org> wrote: > Yeah, especially since there is no such thing as a special "keepalive" packet > in TCP. Keepalive simply sends packets with zero bytes of payload every once > in a while if the connection is otherwise inactive. If those aren't > acknowledged (like every other packet would be) by the peer, the connection > is assumed to be broken. On a reasonably active connection, keepalive neither > causes additional transmissions, nor altered transmissions.
Actualy keep-alive packets contain one byte of data which is a duplicate of the last previously acked byte. > > Keepalive is therefore extremely unlikely to break things - in the very worst > case, a (really, really stupid) firewall might decide to drop packets with > zero bytes of payload, causing inactive connections to abort after a while. > AFAIK walreceiver will simply reconnect in this case. Stateful firewalls whole raison-d'etre is to block packets which aren't consistent with the current TCP state -- such as packets with a sequence number earlier than the last acked sequence number. Keepalives do in fact violate the basic TCP spec so they wouldn't be entirely crazy to block them. Of course a firewall that blocked them would be pretty criminally stupid given how ubiquitous they are. > Plus, the postmaster enables keepalive on all incoming connections *already*, so any problems ought to have caused bugreports about dropped client connections. Really? Since when? I thought there was some discussion about this about a year ago and I made it very clear this had to be an optional feature which defaulted to off. Keepalives introduce spurious disconnections in working TCP connections that have transient outages which is basic TCP functionality that's supposed to work. There are cases where that's what you want but it isn't the kind of thing that should be on by default, let alone on unconditionally. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
