Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions - Mailing list pgsql-hackers

From David Steele
Subject Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions
Date
Msg-id 563BBBD5.1060207@pgmasters.net
Whole thread Raw
In response to Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On 11/5/15 10:10 AM, Alvaro Herrera wrote:
> 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?)

These particular databases were not subject to bloat since they were 
partitioned and append-only - no inserts or deletes whatsoever except to 
tiny dimension tables.  In general, though, you are correct.

An absolute transaction timeout would be a good first step but a 
blocking timeout would also be very handy.  It would be very applicable 
to data warehouse scenarios where bloat is controlled by other means and 
long transactions are the norm (and idle-in-transactions times can also 
be long).

-- 
-David
david@pgmasters.net



pgsql-hackers by date:

Previous
From: Oleg Bartunov
Date:
Subject: Re: Note about comparation PL/SQL packages and our schema/extensions
Next
From: Pavel Stehule
Date:
Subject: Re: Note about comparation PL/SQL packages and our schema/extensions