Re: Nested xact status?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
Cc: Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Nested xact status?
Date: 2004-07-24 18:53:50
Message-ID: 5902.1090695230@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> A previous discarded patch used the static var as means of setting an
> abort point when a function was called. The idea was to close all
> subtransactions opened within the function, so that the user wouldn't be
> presented with subtransactions that the function failed to close. I
> think this is still needed, of course.

I think that functions should not have the ability to do random things
to the subtransaction state, and one of the things that would be right
out is exiting at a different subtransaction nest level than they
started in. It is not practical for xact.c as such to enforce this;
it has to be the responsibility of the functions.

In the case of plpgsql this will be probably be enforced by not offering
direct access to begin/commit/savepoint/rollback at all. IIRC there is
a try/catch-like construct in Oracle pl/sql, and I think what we want to
do is offer that syntax as the interface to creating and rolling back
subtransactions. In other words, TRY does a SAVEPOINT, successful exit
from the TRY block does a RELEASE, and any error inside the TRY block
does a ROLLBACK AND RELEASE then transfers control to the CATCH code.

We probably want to do something roughly similar in SPI as well, ie,
convert the use of savepoints into an implementation detail inside an
API that lets you catch errors in SPI commands you execute. I do not
want people doing SPI_exec("savepoint") or SPI_exec("rollback") because
I don't think it makes any sense.

BTW, whether or not you think that ROLLBACK AND RELEASE is needed at the
SQL level, it is definitely needed at the implementation level. We
don't want useless creation and destruction of a subtransaction every
time a plpgsql function catches an error.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-07-24 20:08:19 Re: make LockRelation use top transaction ID
Previous Message Alvaro Herrera 2004-07-24 15:03:51 Re: make LockRelation use top transaction ID