Alvaro Herrera wrote:
> On Tue, Sep 21, 2004 at 02:30:17PM +0200, Michael Paesold wrote:
> > http://archives.postgresql.org/pgsql-hackers/2004-09/msg00576.php
>
> One potential problem I see with the patch is that it opens lots of
> savepoints but does not release any. In this mode, given autocommit off
> (and even without that), there's potential for lots and lots of
> savepoints. Not sure how to fix that given that you shouldn't release
> user-specified savepoints ...
Well, given that EXCEPTION blocks in Pl/pgSQL and the like also never
release savepoints I think there will be more issues with savepoints in that
area. Nevertheless, I have added a note to the documentation about the
feature that warns of the possible consequences of those many savepoints.
Also Tom Lane mentioned in another thread that even releasing savepoints
does not really help because of the other resources used, e.g. for trx id
locks, that can't be released at all till COMMIT.
> Also, you need to do something with \i. I think the global variable
> will be a less intrusive approach, at least while we are in beta. When
> 8.1 development starts, you can submit a patch to clean up.
I have added a field to the pset settings to do that.
Everything works now as I expected it to do. Using \i and psql <file.sql the
feature is disabled, otherwise it's controlled by the variable
IMPLICIT_SAVEPOINTS and the transaction state (of course not useful when
AUTOCOMMIT is on and no BEGIN issued).
A final thing is the name for this option... I don't really like
IMPLICIT_SAVEPOINTS. Other ideas were AUTO_SAVEPOINT, STATEMENT_SAVEPOINTS
or STATEMENT_ROLLBACK. They aren't really good either...
Patch is attached for review. Please decide if this can be included with
PostgreSQL 8.0 or not. If so, I would like to add a regression test for the
feature. In that case, could you please tell me where to put that one?
Best Regards,
Michael
