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