
> If community will not like UNDO then I'll probably try to implement

Imho UNDO would be great under the following circumstances:
	1. The undo is only registered for some background work process
	    and not done in the client's backend (or only if it is a small txn).
	2. The same mechanism should also be used for outdated tuples
	    (the only difference beeing, that some tuples need to wait longer
	     because of an active xid)

The reasoning to not do it in the client's backend is not only that the client
does not need to wait, but that the nervous dba tends to kill them if after one hour 
of forward work the backend seemingly does not respond anymore (because it is
busy with undo).

> dead space collector which will read log files and so on.

Which would then only be a possible implementation variant of above :-)
First step probably would be to separate the physical log to reduce WAL size.

> to implement logging for non-btree indices (anyway required for UNDO,
> WAL-based BAR, WAL-based space reusing).

Imho it would be great to implement a generic (albeit more expensive) 
redo for all possible index types, that would be used in absence of a physical 
redo for that particular index type (which is currently available for btree).

The prerequisites would be a physical log that saves the page before 
modification. The redo could then be done (with the info from the heap tuple log record)
with the same index interface, that is used during normal operation.

Imho implementing a new index type is difficult enough as is without the need 
to write a redo and undo.

Andreas

Wed, 23 May 2001 09:35:22 +0200
Zeugswetter Andreas SB  <ZeugswetterA@wien.spardat.at>
AW: Plans for solving the VACUUM problem