Re: Idle In Transaction Session Timeout, revived
От | Vik Fearing |
---|---|
Тема | Re: Idle In Transaction Session Timeout, revived |
Дата | |
Msg-id | 56B28480.7010104@2ndquadrant.fr обсуждение исходный текст |
Ответ на | Re: Idle In Transaction Session Timeout, revived (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
Список | pgsql-hackers |
On 02/03/2016 11:36 PM, Jim Nasby wrote: > On 2/3/16 4:05 PM, David Steele wrote: >> On 2/3/16 4:25 PM, Tom Lane wrote: >>> Robert Haas <robertmhaas@gmail.com> writes: >>>> On Wed, Feb 3, 2016 at 3:41 PM, Jim Nasby <Jim.Nasby@bluetreble.com> >>>> wrote: >>>>> Wouldn't it be more sensible to just roll the transaction back and not >>>>> disconnect? >>> >>> I'm not sure how messy this would be in practice. But if we think that >>> killing the whole session is not desirable but something we're doing for >>> expediency, then it would be worth looking into that approach. >> >> I think killing the session is a perfectly sensible thing to do in this >> case. Everything meaningful that was done in the session will be rolled >> back - no need to waste resources keeping the connection open. That was the consensus last time I presented this bikeshed for painting. > Except you end up losing stuff like every GUC you've set, existing temp > tables, etc. For an application that presumably doesn't matter, but for > a user connection it would be a PITA. > > I wouldn't put a bunch of effort into it though. Dropping the connection > is certainly better than nothing. You could always put SET idle_in_transaction_session_timeout = 0; in your .psqlrc file to exempt your manual sessions from it. Or change it just for your user or something. -- Vik Fearing +33 6 46 75 15 36 http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
В списке pgsql-hackers по дате отправления: