Re: Feature freeze date for 8.1 - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Feature freeze date for 8.1
Date
Msg-id Pine.OSF.4.61.0505031936090.347360@kosh.hut.fi
Whole thread Raw
In response to Re: Feature freeze date for 8.1  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Feature freeze date for 8.1  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, 3 May 2005, Tom Lane wrote:

> I am a tad worried about the possibility that if the client does nothing
> for long enough, the TCP output buffer will fill causing the backend to
> block at send().  A permanently blocked backend is bad news from a
> performance point of view (it degrades the sinval protocol for everyone
> else).

Do you mean this scenario:

1. client application doesn't empty its receive buffer (doesn't call   read)
2. server keeps sending data
3. client receive buffer fills
4. server send buffer fills
5. server send blocks.

Unfortunately there's no way to tell if the client is misbehaving or the 
network connection is slow or the client is too busy to handle the data 
fast enough.

I guess we could increase the send buffer (can it be set per-connection?), 
but that only delays the problem.

Does statement_timeout fire on that scenario? How about the new
transaction_timeout option discussed in other threads?

- Heikki


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: distributed database
Next
From: Thomas Hallgren
Date:
Subject: Re: [pgsql-advocacy] Increased company involvement