On Fri, Jun 21, 2002 at 08:30:44PM -0400, Greg A. Woods wrote: > > It should only require REDO. > > No changes are made to the actual database-files until the transaction > > is commited, written to the WAL and fsynced. At this point there is no > > longer a need for UNDO. > > Hmmm.... possibly. I'm not that intimately familiar with the current > WAL implementation, though what I have stated comes directly from the > 7.2.1 manual. If I'm wrong then so is the manual. :-)
I suppose I ought to make it clear that I'm not a postgreSQL developer (haven't even read the code) and my statement is purely based on the manual and and general database knowledge. The manual _does_ state that the main benefit from the WAL is consistency, and it wouldn't be if it made changes to the real database-files before the transaction commited. I totally agree the manual could be clearer on this point. > > I really don't see why relying on WAL is any different from relying on > > other postgresql features - and it is hard to run a postgresql database > > without relying on postgresql.... > > well, the WAL implementation is new, acknowledged to be incomplete, and > so far as I can tell requires additional work on startup.... > > Indeed re-loading a pg_dump will take lots more time, but that's why I > want my DB backups to be done both as a ready-to-roll set of file images > as well as a pg_dump.... :-) Yes, the more redundant backup-solutions the better :) -- Ragnar Kj�rstad Big Storage
