Peter, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > There is a function for that. [...] > There is not a function for that, but there could be one.
I'm not sure you've really considered what you're suggesting here. We need to to make sure we have every file between two LSNs. Yes, we could step the LSN forward one byte at a time, calling the appropriate function for every single byte, to make sure that we have that file, but that really isn't a reasonable approach. Nor would it be reasonable if we go on the assumption that WAL files can't be less than 1MB. Beyond that, this also bakes in an assumption that we would then require access to a database (of a current enough version to have the functions needed too!) to connect to and run these functions, which is a poor design. If the user is using a remote system to gather the WAL on, that system may not have easy access to PG. Further, backup tools will want to do things like off-line verification that the backup is complete, perhaps in another environment entirely which doesn't have PG, or maybe where what they're trying to do is make sure that a given backup is good before starting a restore to bring PG back up. Also, given that one of the things we're talking about here is specifically that we want to be able to change the WAL size for different databases, you would have to make sure that the database you're running these functions on uses the same WAL file size as the one which is being backed up. No, I don't agree that we can claim the LSN -> WAL filename mapping is an internal PG detail that we can whack around because there are functions to calculate the answer. External utilities need to be able to perform that translation and we need to document for them how to do so correctly. Thanks! Stephen
signature.asc
Description: Digital signature
