On Fri, 2004-07-09 at 16:47, Alvaro Herrera wrote:
prominent entry in the docs: "using both nested transactions and
savepoints inside a transaction can cause confusion. We recommend you
stick to one or the other." Or something like that.
(What would really happen: when ROLLBACK TO SAVEPOINT X is executed,
nested transactions created after the SAVEPOINT will be closed.)
So this is another reason why we should use COMMIT to close a nested
transaction: it may refer to a transaction that is already closed
because the user got confused.
On Fri, Jul 09, 2004 at 10:38:15AM -0500, Thomas Swan wrote:
visibility issue and how far do you unwind the depth of subtransactions
or transactions?
BEGIN
UPDATE A
SAVEPOINT X
BEGIN
BEGIN
UPDATE B
BEGIN
UPDATE C
ROLLBACK TO SAVEPOINT X
What happens here is that the user will go nuts. We will have avisibility issue and how far do you unwind the depth of subtransactions
or transactions?
BEGIN
UPDATE A
SAVEPOINT X
BEGIN
BEGIN
UPDATE B
BEGIN
UPDATE C
ROLLBACK TO SAVEPOINT X
prominent entry in the docs: "using both nested transactions and
savepoints inside a transaction can cause confusion. We recommend you
stick to one or the other." Or something like that.
(What would really happen: when ROLLBACK TO SAVEPOINT X is executed,
nested transactions created after the SAVEPOINT will be closed.)
So this is another reason why we should use COMMIT to close a nested
transaction: it may refer to a transaction that is already closed
because the user got confused.
Could we put two modes of operation in?
i.e. if you use SAVEPOINTs/ROLLBACK TO SAVEPOINT, then you're not
allowed to use nested transactions (and vice versa - so they are
mutually exclusive)...
Best Regards, Simon Riggs
