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 по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Bitmap index scans use of filters on available columns