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
signature.asc
Description: OpenPGP digital signature