Well, I'm thinking about WAL last two weeks. Hiroshi pointed me
problems in my approach to savepoints (when a tuple was marked
for update and updated after it) and solution would require
new tid field in header and both t_cmin/t_cmax => bigger header.
I don't like it and so I switched my mind -:).
I'm using "Transaction Processing..." book from Bruce - thanks
a lot, it's very helpful.
I'll come with thoughts and feels in next few days...
Zeugswetter Andreas IZ5 wrote:
>
> > 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".
Me too.
> No need to log before row images eighter, since this is the
> current state of the row during rollforward.
This is true as long as we follow non-overwriting - may be
changed some day.
> 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
It looks like log archiving, not backup.
I believe that _full_ backup will do near the same
things as pg_dump now, but _incremental_ backup will
fetch info about what changed after last _full_ backup
from log.
Vadim
