On Fri, Jun 21, 2002 at 08:43:27PM -0400, Greg A. Woods wrote: > > There are no writes to the filesystem at all while the snapshot is in > > progress. The LVM-driver will block all data-access until it is > > completed. If not, it wouldn't be a snapshot, would it? > > I realize that -- but it doesn't mean the snapshot couldn't begin > between two inter-related writes to two separate files (or even two > separate but inter-related writes to two separate pages in the same > file).
In which case postgreSQL must rely on it's log on startup to finnish the set of write-operations. > If both writes are necessary to result in a consistent DB then > the snapshot will necessarily be inconsistent by definition. Well yes, if you define "consistent" DB to mean you don't have to use the WAL. I find this definition a little strange, as what I care about is if my data is still there (and still correct) when I restore the database. Anyway - we've covered this so let's not go there again. > > Huh? Why would you want a seperate backup of the database transaction > > log? The log is stored in a file together with the rest of the database, > > and will be included in the snapshot and the backup. > > Yeah, but I'm assuming that I'll have to manually UNDO any uncommitted > transactions, as per the 7.2.1 manual..... It says the aborted transactions will occupy space - it doesn't say that you need to manually UNDO them. It doesn't say specificly that you _don't_, but it's the only thing that makes sense; primarely because it's impossible to do manual UNDO. (what if a transaction updated an index but didn't get around to update the table, or the other way around - how do you fix that manually?) -- Ragnar Kj�rstad Big Storage
