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

Re: Continue transactions after errors in psql

From: "Michael Paesold" <mpaesold(at)gmx(dot)at>
To: "Greg Sabino Mullane" <greg(at)turnstep(dot)com>,<pgsql-patches(at)postgresql(dot)org>
Subject: Re: Continue transactions after errors in psql
Date: 2005-01-29 12:04:36
Message-ID: 007101c505fa$b495b480$0a01a8c0@zaphod (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Greg Sabino Mullane wrote:

> Michael Paesold wrote:
>> 2) Implement a server-side function to get the savepoints from the server
>> and query that before every release.
>
> I could not find a way to do this. Is there any interface to the list?

Alvaro suggested to implement such a function. It is not there yet. I think 
you would have to access the sub xact stack, but I have not looked into that 
code for quite some time.
http://archives.postgresql.org/pgsql-general/2004-10/msg00370.php


> First, I'm not of the opinion that it should automatically be turned off
> when running non-interactively. That's too much assuming of what the user
> wants, when this is a settable flag. However, it should be settable via
> a script to a definite state. So \reseterror will take an optional 
> argument,
> "off" or "on", which sets it rather than toggles it.

Discussion here last year showed some concern from people that this feature 
could bite people and is not really safe. Perhaps the best way would be to 
create three states:
\reseterrors (on|off|auto)
where auto means it's only active for interactive queries.
(auto could be named interactive)

> The other problem is not stepping on other people's savepoints. The best
> solution we came up with was to check for savepoint commands ourselves,
> similar to the way psql already checks for transaction affecting commands,
> and handle things appropriately. Specifically, if someone issues a 
> savepoint
> while in \reseterror mode, it switches off automatically*. Since the
> implementation of reseterror is pretty much a lazy shortcut to issuing 
> savepoints
> yourself, it should be safe to say that you do not want to mix manual and
> automatic ones, and we'll back off (with a message) if you issue your own.
> Plus there will be a warning in the docs to be careful about mixing 
> savepoints
> and the \reseterror method.
>
> * We could also switch it back on after rollback or release, but this 
> would
> entail a little more tracking.
>
> Comments?

I would prefer a solution, where the feature is not disabled as soon as I 
use my own savepoints. I like \reseterror because it prevents making typos 
from aborting my transaction. Explicit savepoints I rather use to try a 
whole bunch of statements and then decide if I want to commit so far. I can 
still make typos.

If you don't want to, I can implement such a savepoint stack. I don't think 
it's that hard. The parsing, as you mentioned, should also not be too hard, 
because the infrastructure (removing white space) is already there.

Best Regards,
Michael Paesold 


In response to

Responses

pgsql-hackers by date

Next:From: Stephen FrostDate: 2005-01-29 14:14:38
Subject: Re: [pgsql-hackers] Allow GRANT/REVOKE permissions to be applied to all schema
Previous:From: Victor Y. YegorovDate: 2005-01-29 11:56:12
Subject: Implementing Bitmap Indexes

pgsql-patches by date

Next:From: Alvaro HerreraDate: 2005-01-30 02:47:59
Subject: Re: Continue transactions after errors in psql
Previous:From: Tom LaneDate: 2005-01-29 04:37:51
Subject: Re: more fixes for making contrib null safe

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