On 11/04/2015 12:31 PM, Merlin Moncure wrote:
My issue isn't long statements, but broken client, that is broken in wrong
state - connect is still active, but no any statement will coming.
Right, 'Idle in transaction'. Agree that a setting directed purely at
that problem could set a much lower timeout, say, 5 minutes or less
since it almost never comes up in real applications. In fact, in 15
years of postgres development, I've never seen 'idle transaction' that
indicated anything but application malfunction.
I can +1 that.
That being said, hour timeout for general case would work for me. It
would only have to be set lower for very busy OLTP databases where
continuous vacuum is essential. In those cases, I don't mind forcing
all batch processes to disclose in advance they are running long.
Yeah about an hour sounds right.
JD
merlin
--
Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564
PostgreSQL Centered full stack support, consulting and development.
New rule for social situations: "If you think to yourself not even
JD would say this..." Stop and shut your mouth. It's going to be bad.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
