Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions
В списке pgsql-hackers по дате отправления:
| От | Joshua D. Drake |
|---|---|
| Тема | Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions |
| Дата | |
| Msg-id | 563AA064.9040505@commandprompt.com обсуждение исходный текст |
| Ответ на | Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions (Stephen Frost <sfrost@snowman.net>) |
| Список | pgsql-hackers |
On 11/04/2015 02:53 PM, Stephen Frost wrote: > This implies that a statement used takes a long time. It may not. The > lock is held at the transaction level not the statement level, which is > why a transaction level timeout is actually more useful than a statement > level timeout. > > What I'm most interested in, in the use case which I described and which > David built a system for, is getting that lock released from the lower > priority process to let the higher priority process run. I couldn't care > less about statement level anything. > Ahh, o.k. Yes, I could see the benefit to that. JD > Thanks! > > Stephen -- 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 по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера