Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions
От | Joe Conway |
---|---|
Тема | Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions |
Дата | |
Msg-id | 563BA06C.3090207@joeconway.com обсуждение исходный текст |
Ответ на | Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: Request: pg_cancel_backend variant that handles 'idle
in transaction' sessions
Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions |
Список | pgsql-hackers |
On 11/05/2015 10:09 AM, Pavel Stehule wrote: > On 5.11.2015 19:02 Merlin Moncure wrote: >> Thus, I think we have consensus that transaction_timeout is good -- it >> would deprecate statement_timeout essentially. Likewise, >> pg_cancel_transaction is good and would deprecate pg_cancel_backend; >> it's hard for me to imagine a scenario where a user would call >> pg_cancel_backend if pg_cancel_transaction were to be available. > > I am sorry, I see a consensus between you and Stephen only. S t C a<-------------<transaction>--------------->E r A B A B A n t <idle> <stmt> <idle> <stmt> <idle> d |--------======--------======---------------| Currently we can set timeout and cancel for period B (<stmt>). I can see based on this discussion that there are legitimate use cases for wanting timeout and cancel for any of the periods A, B, or C. I guess the question then becomes how we provide that coverage. I think for coverage of timeout you need three individual timeout settings. However for cancel, it would seem that pg_cancel_transaction would cover all three cases. Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
В списке pgsql-hackers по дате отправления: