Re: Nested transactions: low level stuff

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Manfred Koizar <mkoi-pg(at)aon(dot)at>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Nested transactions: low level stuff
Date: 2003-03-20 03:30:06
Message-ID: 200303200330.h2K3U6r04004@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hiroshi Inoue wrote:
> > > > I think we are a long way from saying we can or will actually do it.
> > > > Error handling and resource management (eg locks) are a couple of other
> > > > huge cans of worms that have yet to be opened. But certainly a solid
> > > > design for the transaction logging and tuple validity checking is a
> > > > necessary step.
> > >
> > > Is the way to undo data rejected already ?
> >
> > You mean abort subtransactions? Each subtransaction gets its own
> > transaction id, so we just mark that as aborted --- there is no undo of
> > tuples, though I had originally suggested that approach years ago.
>
> Vadim planned to implement the savepoints functionality
> using UNDO mechanism. AFAIR it was never denied explicitly.

If you go to the TODO.detail/transactions archive, there was discussion
of using UNDO, and most felt that there were too many problems of having
to manage the undo system, and that assigning a separate transaction id
to every subtransaction was cleaner and more closely matched our
existing system. It also has zero time for undo, which is the case we
have for main transactions now.

--
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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-03-20 03:35:30 Re: Nested transactions: low level stuff
Previous Message Bruce Momjian 2003-03-20 03:26:14 Re: A bad behavior under autocommit off mode