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