Thread

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

Zeugswetter Andreas <andreas.zeugswetter@telecom.at> — 1999-07-07T09:13:15Z

> 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