Greetings, * Greg Stark (st...@mit.edu) wrote: > Including the pre-truncation length in the wal record is the obviously > solid approach and I none of the below is a good substitution for it.
I tend to agree with the items mentioned in Andres's recent email on this thread too in terms of improving the WAL logging around this. > On Tue, 25 Apr 2023 at 13:30, Andres Freund <and...@anarazel.de> wrote: > > It isn't - but the alternatives aren't great either. It's not that easy to > > hit > > this scenario, so I think something along these lines is more palatable than > > adding a pass through the entire data directory. > > Doing one pass through the entire data directory on startup before > deciding the directory is consistent doesn't sound like a crazy idea. We're already making a pass through the entire data directory on crash-restart (and fsync'ing everything too), which includes when restoring from backup. See src/backend/access/transam/xlog.c:5155 Extending that to check for oddities like segments following a not-1GB segment certainly seems like a good idea to me. > It's pretty easy to imagine bugs in backup software that leave out > files in the middle of tables -- some of us don't even have to > imagine... Yup. > Similarly checking for a stray next segment whenever extending a file > to maximum segment size seems like a reasonable thing to check for > too. Yeah, that definitely seems like a good idea. Extending a relation is already expensive and we've taken steps to deal with that and so detecting that the file we were expecting to create is already there certainly seems like a good idea and I wouldn't expect (?) to add a lot of extra time in the normal case. > These kinds of checks are the kind of paranoia that catches filesystem > bugs, backup software bugs, cron jobs, etc that we don't even know to > watch for. Agreed, and would also help in cases where such a situation already exists out there somewhere and which no amount of new WAL records would make go away.. Thanks, Stephen
signature.asc
Description: PGP signature