Re: Two features left

Jon Swinth wrote:
> Maybe what you are talking about will not help. The question is are you
> trying to make nested transactions or savepoints?
>
> Nested transactions would be useful for trying to interrupt a transaction and
> have another action happen or not happen on it's own. An example would be
> when you want a credit card transaction to generate a log reguardless of
> whether the out transaction is commited or rolled back. The problem with

Not with my implementation:

> > BEGIN;
> > SELECT ...
> > BEGIN;
> > UPDATE ...
> > ABORT;
> > DELETE ...
> > COMMIT;

In the above case, the ABORT cancels the UPDATE. If the outer
transaction ABORTS, everything aborts. Even if you commit a
subtransaction, _all_ transactions above it must commit for the
subtransaction to actually commit.

If you want a log entry regardless of the transaction, put it in a
separate transaction.

> nested transactions is that it is easy to generate deadlocks, especially with
> the write locks currently on foreign keys.

Again, it isn't really any different from a transaction without
subtransactions except certain parts of the entire transaction can be
aborted.

> What may help is the concept of savepoint (if implemented internally).
> Savepoints are usually named and allow rollback to a specific point in the
> transaction. There is no issue with deadlock since everything is still in
> the same transaction. You then don't have to have something call ABORT, you
> simple need to say ROLLBACK TO <savepoint_name>.
>
> BEGIN;
> SELECT...
> INSERT...
> SAVEPOINT a ;
> UPDATE...
> ROLLBACK TO a ;
> DELETE...
> COMMIT;

Right. It is no change in functionality to add savepoints because we
can just do a named BEGIN internally as the SAVEPOINT, then do ABORT
back until we match the nesting level of the savepoint.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073