From: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Joe Conway <mail(at)joeconway(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, David Steele <david(at)pgmasters(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions |
Date: | 2015-11-04 22:24:39 |
Message-ID: | 563A85A7.7050806@commandprompt.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-11-04 22:32:37 | Re: Bitmap index scans use of filters on available columns |
Previous Message | Stephen Frost | 2015-11-04 22:15:32 | Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions |