Re: Idle In Transaction Session Timeout, revived
От | Robert Haas |
---|---|
Тема | Re: Idle In Transaction Session Timeout, revived |
Дата | |
Msg-id | CA+TgmoZ5RDQCE01JJxnysqM5YaZ5W-pS1zz1__2CxQ-S3+QbBg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Idle In Transaction Session Timeout, revived (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
Ответы |
Re: Idle In Transaction Session Timeout, revived
|
Список | pgsql-hackers |
On Wed, Feb 3, 2016 at 3:41 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote: > On 2/3/16 2:30 PM, Robert Haas wrote: >> >> On Sun, Jan 31, 2016 at 8:33 AM, Vik Fearing <vik@2ndquadrant.fr> wrote: >>> >>> Attached is a rebased and revised version of my >>> idle_in_transaction_session_timeout patch from last year. >>> >>> This version does not suffer the problems the old one did where it would >>> jump out of SSL code thanks to Andres' patch in commit >>> 4f85fde8eb860f263384fffdca660e16e77c7f76. >>> >>> The basic idea is if a session remains idle in a transaction for longer >>> than the configured time, that connection will be dropped thus releasing >>> the connection slot and any locks that may have been held by the broken >>> client. >>> >>> Added to the March commitfest. >> >> >> +1 for doing something like this. Great idea! > > > Wouldn't it be more sensible to just roll the transaction back and not > disconnect? It would be nice to be able to do that, but the client-server protocol can't handle it without losing sync. Basically, if you send an error to an idle client, you have to kill the session. This has come up many times before. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: