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
|
Список | 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? Somepossibilities:a. Reset the session related variables like transaction, preparedstatements, etc. and retain it for connection pool kind of stuffb. 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 betterto have just a single time out (session_idle_timeout/idle_timeout)
В списке pgsql-hackers по дате отправления: