On Mon, 02 May 2005 01:35:14 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
>[ itch... ] This seems to me to be conflating several
>distinct issues.
>AFAIR the points that have been raised in the thread are:
>
>#1 Defend against loss of connectivity to client
>#2 Defend against client sitting idle while holding locks
(or just holding an open transaction and thereby
preventing VACUUM cleanup)
>#3 Defend against client holding locks unreasonably long,
>even though not idle (obviously any such constraint will
cause clients to
> fail midstream, but perhaps some DBAs will see this as
the lesser of two evils)
>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.
>#2 is a fair point if you need to cope with
poorly-programmed clients,
>but I'm not seeing exactly why it has to be measured by
"idle time"
>rather than "total time". The known cases of this involve
>client code that issues a BEGIN and then just sits, so
there's no
>difference.
Ok, the client sent BEGIN and then connection was lost.
Does it means that the client sits ?
Adnan DURSUN
ASRIN Bilişim Hiz.Ltd.
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
