Re: [HACKERS] RE: [GENERAL] Transaction logging

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