Re: idle_in_transaction_timeout
| От | Vik Fearing |
|---|---|
| Тема | Re: idle_in_transaction_timeout |
| Дата | |
| Msg-id | 538E6E59.2020602@dalibo.com обсуждение исходный текст |
| Ответ на | Re: idle_in_transaction_timeout (David G Johnston <david.g.johnston@gmail.com>) |
| Список | pgsql-hackers |
On 06/04/2014 02:01 AM, David G Johnston wrote:
Default to dropping the connection but give the usersadministrators the capability to decide for themselves?
Meh.
I still haven't heard an argument for why this wouldn't apply to aborted idle-in-transactions. I get the focus in on releasing locks but if the transaction fails but still hangs around forever it is just as broken as one that doesn't fail and hangs around forever.
My main concern was with locks and blocking VACUUM. Aborted transactions don't do either of those things. The correct solution is to terminate aborted transaction, too, or not terminate anything and abort the idle ones.
Even if you limit the end result to only aborting the transaction the end-user will likely want to distinguish between their transaction failing and their failed transaction remaining idle too long - if only to avoid the situation where they make the transaction no longer fail but still hit the timeout.
But hitting the timeout *is* failing.
With the new patch, the first query will say that the transaction was aborted due to timeout. Subsequent queries will do as they've always done.
-- Vik
В списке pgsql-hackers по дате отправления: