On Fri, Jun 21, 2002 at 05:17:35PM -0400, Greg A. Woods wrote: > Yes, I agree with this, assuming you're talking about an increment to > the currently available release that puts you up ahead to some mythical > future vapour-ware. The ability to reliably restore consistency in such > a backup copy of the files not only depends on write-ahead-logging > support, but also on properly functioning REDO _and_ UNDO functions.
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. > I.e. PostgreSQL releases up to, and including, 7.2.1 do not provide a > way to guarantee a database is always recoverable to a consistent state. > Current releases do not have a built-in way to remove changes already > made to data pages by uncomitted transactions. But it doesn't do changes to the data-pages until the transaction is commited. If it had; your database would have been toast if you lost power. (or at least not correct) > When you restore a database from backups you really do want to just > immediately start the database engine and know that the restored files > have full integrity. You realy don't want to have to rely on W.A.L. 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.... > When you restore a database from backups during a really bad disaster > recovery procedure you sometimes don't even want to have to depend on > the on-disk-file format being the same. You want to be able to load the > data into an arbitrary version of the software on an arbitrary platform. Yes; unfortenately this is not even possible with pg_dump. (it is better than a filesystem backup in this regard, but there are still version-incompabilities that have to be fixed manually) -- Ragnar Kj�rstad Big Storage
