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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
