Re: Idle In Transaction Session Timeout, revived
От | Vik Fearing |
---|---|
Тема | Re: Idle In Transaction Session Timeout, revived |
Дата | |
Msg-id | 56B35916.9080601@2ndquadrant.fr обсуждение исходный текст |
Ответ на | Re: Idle In Transaction Session Timeout, revived (Fujii Masao <masao.fujii@gmail.com>) |
Список | pgsql-hackers |
On 02/04/2016 02:24 PM, Fujii Masao wrote: > On Sun, Jan 31, 2016 at 10:33 PM, 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. > > +1 > > But, IIRC, one of the problems that prevent the adoption of this feature is > the addition of gettimeofday() call after every SQL command receipt. > Have you already resolved that problem? Or we don't need to care about > it because it's almost harmless? I guess it would be possible to look at MyBEEntry somehow and pull st_state_start_timestamp from it to replace the call to GetCurrentTimestamp(), but I don't know if it's worth doing that. The extra call only happens if the timeout is enabled anyway, so I don't think it matters enough to be a blocker. -- Vik Fearing +33 6 46 75 15 36 http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
В списке pgsql-hackers по дате отправления: