> Added to TODO:
>
> * Transaction log, so re-do log can be on a separate disk by
> logging SQL queries, or before/after row images
>
I would drop the "log SQL queries idea".
No need to log before row images eighter, since this is the
current state of the row during rollforward.
(For asserts a checksum of the before image would be sufficient,
but IMHO not necessary.)
I suggest:
* Transaction log that stores after row (or even only column)
images,
which can be put on a separate disk to allow rollforward after
a restore of a server.
The "restore of a server" is a main problem here, but I suggest the
following
additional backup tool, that could be used for a "restore of a server"
which could then be used for a rollforward and would also be a lot faster
than a pg_dump:
1. place a vacuum lock on db (we don't want vacuum during backup)
2. backup pg_log using direct file access (something like dd bs=32k)
3. backup the rest in any order (same as pg_log)
4. release vacuum lock
If this was restored, this should lead to a consistent database,
that has all transactions after the start of backup rolled back.
Is there a nono in this idea? I feel it should work.
A problem is probably, that the first to touch a row with a committed update
stores this info in that row. There would probably need to be an undo for
this
after restore of the physical files.
Andreas
