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.
I am sorry, but I have a different experience from GoodData. The few hours autovacuum is usual. So probably, there should be exception for autovacuum, dump, ..
Regards
Pavel
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.
