On Jun 21, 2010, at 0:13 , Greg Stark wrote:
>> 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.
Keepalives play games with the spec, but they don't outright violate it I'd
say. The sender bluffs by retransmitting data it *knows* has been ACK'ed. But
since nobody else can prove with certainty that the sender actually saw that
ACK (think NIC-internal buffer overflow), nobody is able to call that bluff.
> Of course a firewall that blocked them
> would be pretty criminally stupid given how ubiquitous they are.
Very true, and another reason to stop worrying about possibly brain-dead
firewalls.
>> 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.
Since 'bout 10 years. The setsockopt call is in StreamConnection() in
src/backend/libpq/pqcomm.c.
Here's the corresponding commit:
commit 5aa160abba32a1f2d7818b9f49213f38c99b3fd8
Author: Tatsuo Ishii <is...@postgresql.org>
Date: Sat May 20 13:10:54 2000 +0000
Add KEEPALIVE option to the socket of backend. This will automatically
terminate the backend that has no frontend anymore.
> 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.
I'd buy that if all timeouts and retry counts would default to +infinity. But
they don't, and hence sufficiently long network outages *will* cause connection
aborts anyway. That a particular connection might survive due to inactivity
proves nothing, since whether the connection is active or inactive during an
outage is usually outside of anyone's control.
I really fail to see why anyone would prefer connections (and therefore
transactions!) getting stuck forever over a few spurious disconnects. The
former always require manual intervention and cause all sorts of performance
and disk-space issues, while the latter won't even be an issue for well-written
clients who just reconnect and retry.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
