From: | "Vadim Mikheev" <vmikheev(at)reveredata(dot)com> |
---|---|
To: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Bruce Momjian" <pgman(at)candle(dot)pha(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 04:28:08 |
Message-ID: | 006201c2ee99$1cfa06f0$15f5fea9@home |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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.
Somehow it's working in other DB systems.
> 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 ...
Each access-method requires specific UNDO code (like REDO).
Once again, it works in other DB-es.
Vadim
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2003-03-20 04:30:42 | Re: Nested transactions: low level stuff |
Previous Message | Bruce Momjian | 2003-03-20 04:23:58 | Re: A bad behavior under autocommit off mode |