On Mon, 2 May 2005, Tom Lane wrote:
> #1 Defend against loss of connectivity to client
>
> I claim that if you have a problem with #1 you ought to go discuss it
> with some TCP hackers: you basically want to second-guess the TCP
> stack's ideas about appropriate timeouts. Maybe you know what you
> are doing or maybe not, but it's not a database-level issue.
Different applications can have different needs here. For some it's okay
to wait a long time, for others it is not.
The tcp hackers have provided an api for clients to set these values per
socket (setsockopt with TCP_KEEPIDLE and similar (in linux at least)).
My problem with the above setting is that some operations can be in
progress for a long time on the server without generating any tcp/ip
traffic to the client (a non verbose vacuum I guess is such a case). Such
an operation would look like it's idle.
There is an overlap with session and transaction timeouts, most
applications work fine with any of these.
--
/Dennis Björklund
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
