Updated TODO:
* Transaction log, so re-do log can be on a separate disk by
with after-row images
> > 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
>
>
>
--
Bruce Momjian | http://www.op.net/~candle
maillist@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
