On Thu, Nov 5, 2015 at 12:31 PM, Joe Conway <m...@joeconway.com> wrote: > 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.
Agreed on all points. Tom noted earlier some caveats with the 'idle' timeout in terms of implementation. Maybe that needs to be zeroed in on. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
