> 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
foroutdated 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
