Re: Feature freeze date for 8.1

On Mon, 02 May 2005 01:35:14 -0400
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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.