Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions
От | Joshua D. Drake |
---|---|
Тема | Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions |
Дата | |
Msg-id | 563A85A7.7050806@commandprompt.com обсуждение исходный текст |
Ответ на | Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: Request: pg_cancel_backend variant that handles 'idle
in transaction' sessions
|
Список | pgsql-hackers |
On 11/04/2015 02:15 PM, Stephen Frost wrote: >> Yeah but anything holding a lock that long can be terminated via >> statement_timeout can it not? > > Well, no? statement_timeout is per-statement, while transaction_timeout > is, well, per transaction. If there's a process which is going and has > an open transaction and it's holding locks, that can be an issue. No, what I mean is this: BEGIN; select * from foo; update bar; delete baz; Each one of those is subject to statement_timeout, yes? If so, then I don't see a point for transaction timeout. You set statement_timeout for what works for your environment. Once the timeout is reached within the statement (within the transaction), the transaction is going to rollback too. JD -- Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564 PostgreSQL Centered full stack support, consulting and development. New rule for social situations: "If you think to yourself not even JD would say this..." Stop and shut your mouth. It's going to be bad.
В списке pgsql-hackers по дате отправления: