Skip site navigation (1) Skip section navigation (2)

Re: idle in txn query cancellation

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>
Subject: Re: idle in txn query cancellation
Date: 2010-02-15 10:43:36
Message-ID: 201002151143.37382.andres@anarazel.de (view raw or flat)
Thread:
Lists: pgsql-hackers
On Monday 15 February 2010 09:47:09 Simon Riggs wrote:
> On Sat, 2010-02-13 at 22:37 +0100, Andres Freund wrote:
> > On a related note I would also like to get rid of the restriction that
> > a normal query cancellation will only be done if no subtransactions
> > are stacked.
> > But I guess its too late for that? (I have a patch ready, some cleanup
> > would be needed)
> > The latter works by:
> > - adding a explicit error code (which should be done regardless of
> > this
> > discussion)
> > - avoiding to catch such error at a few places (plperl, plpython)
> > - recursively aborting the subtransactions once the mainloop is
> > reached
> > - relying on the fact that the cancellation signal will get resent
> > - possibly escalating to a FATAL if nothing happens after a certain
> > number of tries
> 
> Such an action needs to have a good, clear theoretical explanation with
> it to show that the interaction with savepoints is a good one.
I can provide a bit more explanation. The patch (other thread) already added 
some more comments but its definitely good to explain/define some more.
Will post that to the thread with the patch, ok?

> I toyed with the idea of a new level between ERROR and FATAL to allow
> ERRORs to be handled by savepoints still in all cases.
I have a hard time believing that it will help in that situation. Either you 
allow cleaning up process local resources in PG_TRY/PG_TRY in which situation 
you cant abort recursively at all places because the catching code block may 
very well reference resources associated with that snapshot or you abort the 
process in a way that there are no process local resources.

How would the middleway between those work?

Andres

In response to

pgsql-hackers by date

Next:From: Tim BunceDate: 2010-02-15 10:51:14
Subject: Re: PostgreSQL::PLPerl::Call - Simple interface for calling SQL functions from PostgreSQL PL/Perl
Previous:From: Richard HuxtonDate: 2010-02-15 10:42:15
Subject: Re: PostgreSQL::PLPerl::Call - Simple interface for calling SQL functions from PostgreSQL PL/Perl

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group