Re: Two features left

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

In response to

Responses

Browse pgsql-general by date

  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