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