Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions
| От | Pavel Stehule |
|---|---|
| Тема | Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions |
| Дата | |
| Msg-id | CAFj8pRD28_JKA345iCmYN3vMYm+m1hnpdnEw3Sm5GuMexEwvxQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions ("Joshua D. Drake" <jd@commandprompt.com>) |
| Ответы |
Re: Request: pg_cancel_backend variant that handles 'idle
in transaction' sessions
|
| Список | pgsql-hackers |
2015-11-04 21:56 GMT+01:00 Joshua D. Drake <jd@commandprompt.com>:
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.
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.
В списке pgsql-hackers по дате отправления: