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

Re: Continue transactions after errors in psql

From: "Greg Sabino Mullane" <greg(at)turnstep(dot)com>
To: pgsql-patches(at)postgresql(dot)org
Subject: Re: Continue transactions after errors in psql
Date: 2005-01-29 04:09:20
Message-ID: 26efc15145188e1a198f2e7f30d31393@biglumber.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
 
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?
</aside>
 
I looked over the patch from Michael Paesold, and talked extensively with
Robert Treat about this, and here is the solution Robert and I came up with:
(thanks to both for their work)
 
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.
 
The patch Robert provided shold catch the problem of "good command-commit".
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?
 
- --
Greg Sabino Mullane greg(at)turnstep(dot)com
PGP Key: 0x14964AC8 200501282306
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
 
-----BEGIN PGP SIGNATURE-----
 
iD8DBQFB+wzovJuQZxSWSsgRAt5eAJ9BVMtYZ9H+A76cNdUuhv4GpXeCwQCdFVsi
+mgg6ZzMylgHgdfiVn4yI5o=
=CpZQ
-----END PGP SIGNATURE-----



In response to

Responses

pgsql-hackers by date

Next:From: Greg Sabino MullaneDate: 2005-01-29 04:20:04
Subject: Re: working on support triggers on columns
Previous:From: Greg Sabino MullaneDate: 2005-01-29 02:55:52
Subject: Re: Patent issues and 8.1

pgsql-patches by date

Next:From: Tom LaneDate: 2005-01-29 04:37:51
Subject: Re: more fixes for making contrib null safe
Previous:From: Jon JensenDate: 2005-01-29 03:21:41
Subject: Re: more fixes for making contrib null safe

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