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

Re: Continue transactions after errors in psql

From: "Michael Paesold" <mpaesold(at)gmx(dot)at>
To: "Alvaro Herrera" <alvherre(at)dcc(dot)uchile(dot)cl>
Cc: "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-30 17:41:34
Message-ID: 003e01c506f3$0f3665d0$0a01a8c0@zaphod (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
Alvaro Herrera wrote:

>> >Michael Paesold wrote:
>> 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.
> The only problem with this idea is that the function cannot be run when
> the transaction is in aborted state.  Not sure if that is a problem or
> not.  What happens if the user does

I don't think there is a problem. If the transaction is in aborted state, we 
only care if the last statement has aborted the transaction. Otherwise we 
would not issue our savepoint at all. In that case, i.e. if the last 
statement aborted the transaction, we can roll it back anyway, can't we? 
There can't be a savepoint on top of us, because that would have failed 
right now.
Is my logic wrong?

> all in one command in psql?
> I know psql sends that as three commands, so maybe it's not an issue.

As far as I remember psql splits the three commands, so there would be an 
implicit savepoint for each individual statement:

* SAVEPOINT pg_psql_savepoint; -- [1]
* SAVEPOINT pg_psql_savepoint; -- [2]
* ROLLBACK TO pg_psql_savepoint; -- [2]
* SAVEPOINT pg_psql_savepoint; -- [3]
* RELEASE pg_psql_savepoint; -- [3]
* RELEASE pg_psql_savepoint; -- [1], because pg_psql_savepoint is on top of 
the stack now again

I hope you get the point. ;-)

Do you think it's better to create a server-side function or handle that in 
the client? How hard would it be to implement such a function? And what 
should it return? Only the name of the current top savepoint?

Best Regards,
Michael Paesold

In response to


pgsql-hackers by date

Next:From: Marc G. FournierDate: 2005-01-30 19:03:41
Subject: Packaging begins in 4 hours ...
Previous:From: John HansenDate: 2005-01-30 10:34:40
Subject: Rtree index method for inet/cidr

pgsql-patches by date

Next:From: Alvaro HerreraDate: 2005-01-31 02:04:54
Subject: Re: Shared dependency patch
Previous:From: Peter EisentrautDate: 2005-01-30 15:47:37
Subject: Re: Turkish translation updates for 8.0.1

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