| 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-05 00:18:44 |
| Message-ID: | 563AA064.9040505@commandprompt.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2015-11-05 00:20:53 | Re: WIP: Make timestamptz_out less slow. |
| Previous Message | Pavel Stehule | 2015-11-04 23:37:39 | Re: [patch] Proposal for \rotate in psql |