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.
It can be difficult to set it properly, because you don't know how much statements (cycles of A.B) will be in transaction. Respective for setting C, I have to know the number of A,B and it isn't possible everytime.
Regards
Pavel
Joe
-- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
