Re: Feature freeze date for 8.1

On E, 2005-05-02 at 01:35 -0400, Tom Lane wrote:
> Neil Conway <neilc(at)samurai(dot)com> writes:
> > Tom Lane wrote:
> >> We would? Why? Please provide a motivation that justifies the
> >> considerably higher cost to make it count that way, as opposed to
> >> time-since-BEGIN.
>
> > The specific scenario this feature is intended to resolve is
> > idle-in-transaction backends holding on to resources while the network
> > connection times out; it isn't intended to implement "I never want to
> > run a transaction that takes more than X seconds to execute."
>
> [ 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.

Well, I've had problems with clients which resolve DB timeouts by
closing the current connection and establish a new one.

If it is actual DB timeout, then it all is ok, the server soon notices
that the client connection is closed and kills itself.

Problems happen when the timeout is caused by actual network problems -
when i have 300 clients (server's max_connections=500) which try to
reconnect after network outage, only 200 of them can do so as the server
is holding to 300 old connections.

In my case this has nothing to do with locks or transactions.

It would be nice if I coud st up some timeut using keepalives (like ssh-
s ProtocoKeepalives") and use similar timeouts on client and server.

--
Hannu Krosing <hannu(at)skype(dot)net>