Re: Feature freeze date for 8.1

Tom Lane wrote:
> #3  Defend against client holding locks unreasonably long, even though
>     not idle

I can't get too excited about this case. If the client is malicious, 
this feature is surely insufficient to stop them from consuming a lot of 
resources (for example, they could easily drop and then reacquire the 
locks every (timeout * 0.9) seconds). And how many DBAs are really going 
to want to abort non-malicious clients doing useful work if they happen 
to exceed a certain total runtime? Perhaps a motivating example would 
help...

> 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.

Well, no -- you might want to set a different timeout for PostgreSQL 
connections than for other connections. Is there a way to change the 
socket timeout for some subset of the processes on the machine without 
hacking the client or server source? You might also want to set this 
timeout on a more granular basis (e.g. per user, per database, etc.) 
Implementing this via setting a socket option (provided it can be done 
portably) would be fine with me.

-Neil