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 CAFj8pRDzYz+wzEazk_RUYMs4ADqby_gJaCQUNf=OH=ruZ6mATw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
Дерево обсуждения


2015-11-03 3:42 GMT+01:00 Amit Kapila <amit.kapila16@gmail.com>:
On Mon, Nov 2, 2015 at 10:45 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:

It is 100% true. But the users can do strange things. If we solve idle transactions and not idle session, then they are able to increase max_connections to thousands with happy smile in face.

I have not strong idea about how to solve it well - maybe introduce transaction_idle_timeout and session_idle_timeout?


What exactly do we want to define session_idle_timeout?  Some
possibilities:
a. Reset the session related variables like transaction, prepared
statements, etc. and retain it for connection pool kind of stuff
b. Exit from the session

b is safe state - and currently it is only one state, that we can forward to client side (with keep_alive packets) - so I prefer b

Regards

Pavel
 

If we want something on lines of option (a), then I think it is better
to have just a single time out (session_idle_timeout/idle_timeout)



With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Merlin Moncure
Дата:
Сообщение: Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: COPY FREEZE and PD_ALL_VISIBLE