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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-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

Browse pgsql-hackers by date

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

Browse pgsql-patches by date

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