| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | David Steele <david(at)pgmasters(dot)net> |
| Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Joe Conway <mail(at)joeconway(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(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>, 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 15:10:06 |
| Message-ID: | 20151105151006.GU6104@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
David Steele wrote:
> The important thing about this implementation was that nothing was
> terminated unless it had exceed a timeout AND was blocking another
> process.
This seems a nice idea, but you need to take the effect on vacuum of
idle-in-xact sessions too. If the operator left for the day and their
session doesn't block any other process, the next day you could find
some tables bloated to such extreme as to cause problems later on.
Surely the operator can review their terminal to re-do the work, in case
it was valuable. (If it was valuable, why didn't they commit the
transaction?)
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zeus Kronion | 2015-11-05 15:11:56 | Re: WIP: Fix parallel workers connection bug in pg_dump (Bug #13727) |
| Previous Message | YUriy Zhuravlev | 2015-11-05 14:57:56 | Re: Some questions about the array. |