On Feb 9, 2008 5:50 AM, Greg Smith <gsmith@xxxxxxxxxxxxx> wrote: > On Fri, 8 Feb 2008, David Wall wrote: > > > Does pg_standby take care of this by checking file sizes or the like? In my > > testing with scp, we never experienced any problems, but I wonder if we were > > somehow "just lucky." > > pg_standby only processes files of exactly the length they're supposed to > be. On Windows it even sleeps a bit after that to give time for things to > settle. > > The main risky situation you could end up in is if you were using a copy > program that created the whole file at its full size first then wrote the > data to it. I don't think there are many programs that operate like that > around and certainly scp doesn't do that. > "atomic tool": The reason rsync is used in the archive_command is that rsync features an 'atomic copy' - that is, the in-progress destination file is created as a temp file, and then renamed when the copy is complete. In the situation above, where segments are archived straight to the directory that the slave reads from, 'cp' can cause an error whereby the slave attempts to process a partially-copied WAL segment. If this happens, postgres will emit an error like: PANIC: archive file "000000010000000000000031" has wrong size: 1810432 instead of 16777216 LOG: startup process (PID 11356) was terminated by signal 6 LOG: aborting startup due to startup process failure taken from http://archives.postgresql.org/sydpug/2006-10/msg00001.php thanks everybody!! -- Roberto Scattini ___ _ ))_) __ )L __ ((__)(('(( ((_) ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
