From: | Jean-Luc Lachance <jllachan(at)nsd(dot)ca> |
---|---|
To: | Jon Swinth <jswinth(at)atomicpc(dot)com> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Two features left |
Date: | 2002-11-27 21:45:34 |
Message-ID: | 3DE53CFE.617958EA@nsd.ca |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Jon,
That is all fine and dandy, but aren't function start point candidate
for a rollback to point?
A transaction is currently implicitely started on function call, and we
get into the same problem as with nested transaction when a function
calls another one.
Don't get me wrong, I thing SAVEPOINT and ROLLBACK TO is a great idea,
but nested transaction is needed.
JLL
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
> nested transactions is that it is easy to generate deadlocks, especially with
> the write locks currently on foreign keys.
>
> 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;
>
> On Wednesday 27 November 2002 12:25 pm, Bruce Momjian wrote:
> > Jean-Luc Lachance wrote:
> > > Bruce,
> > >
> > > I assume one will be able to ABORT the current transaction without
> > > aborting the higher transaction and ABORT ALL to abort all if needed.
> >
> > Right. I hadn't planned on ABORT ALL, but it could be done to abort the
> > entire transaction. Is there any standard on that?
> >
> > > What syntax will be available to the upper transaction to detect a lower
> > > ABORT?
> > > While there be something ? la Java ( try catch)?
> >
> > My initial implementation will be simple:
> >
> > BEGIN;
> > SELECT ...
> > BEGIN;
> > UPDATE ...
> > ABORT;
> > DELETE ...
> > COMMIT;
> >
> > and later savepoints which allow you to abort back to a saved spot in your>
> transaction.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
From | Date | Subject | |
---|---|---|---|
Next Message | Jean-Luc Lachance | 2002-11-27 21:51:17 | Re: Two features left |
Previous Message | Ron St.Pierre | 2002-11-27 21:38:54 | Sequence (related) Problem |