#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
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org
