Many thanks for the reply. I dug through the log files and found that the archiving had been failing, so it stands a good chance I'd pulled 1B out of the xlog directory ahead of time. Over the course of the weekend (once I've upgraded to v8.1.3) I'll try the exercise again and see what happens.
As for digging through xlog.c, I'm not a C programmer so I'll stay right out of the way - leave that to you guys!!
Note there are plenty more files ready to run in the archive, and the
contents of the backup label only mention 1A as the final WAL file of
the backup, so it is starting to read the next WAL file, but stopping
for some reason. Is it because of the "record with zero length" that's
causing it to fail?
Yes --- that indicates the end of archive. It sounds to me like file 1B
was archived while still only partly filled. Check the process you're
using for deciding when to copy WAL files.
Also why is it restoring 1B from the archive twice?
I think that's expected behavior --- it has something to do with wanting
to make the copy of 1B into the new writable front WAL segment. You can
dig through xlog.c if you want the details.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
!DSPAM:43f5e383306306701047853!