Re: Nested transactions: low level stuff

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, 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:42:20
Message-ID: 200303200342.h2K3gKW05642@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> writes:
> > Bruce Momjian wrote:
> >> 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.
>
> Given all the flak we got about WAL growth during the time we had that
> code enabled, I think there's no chance that UNDO will be the preferred
> path. It's not workable with big transactions.
>
> There are other problems besides WAL bloat, too. I realized while I was
> working on the btree code a few weeks ago that it's fundamentally
> unfriendly to UNDO, because there are some operations you'd want to
> UNDO (viz, insertion of a leaf item pointing at a heap tuple) and some
> you would not (viz, splitting of index pages and subsequent insertion of
> items into upper tree levels). But the same WAL entry might include
> both kinds of operation. This could be got round, perhaps, but that
> code is overcomplicated already ...

I assumed the UNDO would have had to be in a separate place, or allow
compression of the WAL file to keep needed UNDO stuff but get rid of
unneeded stuff --- it was all quite complicated.

--
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:51:32 Faster NUMERIC implementation
Previous Message Shridhar Daithankar 2003-03-20 03:42:12 Re: PostgreSQL flamage on Slashdot