At 11:25 23/05/01 +0200, Zeugswetter Andreas SB wrote:
>
>> >If community will not like UNDO then I'll probably try to implement
>> >dead space collector which will read log files and so on. 
>> 
>> I'd vote for UNDO; in terms of usability & friendliness it's a big win.
>
>Could you please try it a little more verbose ? I am very interested in 
>the advantages you see in "UNDO for rollback only".

I have not been paying strict attention to this thread, so it may have
wandered into a narrower band than I think we are in, but my understanding
is that UNDO is required for partial rollback in the case of failed
commands withing a single TX. Specifically,

- A simple typo in psql can currently cause a forced rollback of the entire
TX. UNDO should avoid this.

- It is not uncommon for application in other databases to handle errors
from the database (eg. missing FKs), and continue a TX.

- Similarly, when we get a new error reporting system, general constraint
(or other) failures should be able to be handled in one TX.


----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|
                                 |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/

Wed, 23 May 2001 20:43:24 +1000
Philip Warner <pjw@rhyme.com.au>
Re: AW: Plans for solving the VACUUM problem
> >> I'd vote for UNDO; in terms of usability & friendliness it's a big win.
> >
> >Could you please try it a little more verbose ? I am very interested in 
> >the advantages you see in "UNDO for rollback only".

The confusion here is that you say you want UNDO, but then say you want
it to happen in the background, which sounds more like autovacuum than
UNDO.

> I have not been paying strict attention to this thread, so it may have
> wandered into a narrower band than I think we are in, but my understanding
> is that UNDO is required for partial rollback in the case of failed
> commands withing a single TX. Specifically,
> 
> - A simple typo in psql can currently cause a forced rollback of the entire
> TX. UNDO should avoid this.
> 
> - It is not uncommon for application in other databases to handle errors
> from the database (eg. missing FKs), and continue a TX.
> 
> - Similarly, when we get a new error reporting system, general constraint
> (or other) failures should be able to be handled in one TX.

I think what you are asking for here is subtransactions, which can be
done without UNDO if we assign a unique transaction id's to each
subtransaction.  Not pretty, but possible.  

UNDO makes subtransactions easier because you can UNDO the part that
failed.  However, someone mentioned you may have to wait for that part
to be undone.  I think you have to wait because the current transaction
would have no way to know which rows were visible to the current
transaction unless you mark them right away or grope through the WAL
every time you visit a tuple.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Wed, 23 May 2001 11:27:57 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: AW: Plans for solving the VACUUM problem