* Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> [100211 09:17]:
> If the file is just being copied to the archive when restore_command > ('cp', say) is launched, it will copy a half file. That's not a problem > for PITR, because PITR will end at the end of valid WAL anyway, but > returning a half WAL file in standby mode is a problem. But it can be a problem - without the last WAL (or at least enough of it) the master switched and archived, you have no guarantee of having being consistent again (I'm thinking specifically of recovering from a fresh backup) > Yeah, if you're careful about that, then this change isn't required. But > pg_standby protects against that, so I think it'd be reasonable to have > the same level of protection built-in. It's not a lot of code. This 1 check isn't, but what about the rest of the things pg_standby does. How much functionality should we bring it? Ideally, "all" of it. > We could well just document that you should do that, ie. make sure the > file appears in the archive atomically with the right size. I have to admit, today was the first time I went and re-read the PITR docs, and no, the docs don't seem to talk about that... Maybe it was just plain obvious to me because it (the atomic apperance) is something unix devloppers have always had to deal with, so it's ingrained in me. But I'm *sure* that I've seen that bandied around as common knowledge on the lists, and one of the reasons we alway see warnings about using rsync instead of plain SCP, etc. So ya, we should probably mention that somewhere in the docs. Section 24.3.6. Caveats? a. -- Aidan Van Dyk Create like a god, ai...@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
signature.asc
Description: Digital signature