On Mon, 2007-12-31 at 12:33 -0500, Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> writes: > > On Mon, 2007-12-31 at 11:53 -0500, Tom Lane wrote: > >> The state of the ...0058 file might be explained by the theory that > >> you'd archived it a bit too late (after the first page had been > >> overwritten with newer WAL data), > > > The interlock with .ready and .done should prevent reuse of a file. So > > the only way this could happen is if the archive_command queued a > > request to copy, rather than performing the copy immediately. > > So I was going to say "thats not possible", but perhaps rsync might > > become confused by the file renaming mechanism we use? > > Actually, the other problem with that theory is that the slave swallowed > the file without complaint.
No, it barfed. Mason showed us a recovery script, so it came from the slave. > Since the WAL reader code does check that > the page header contains the expected address, this seems to imply that > what the slave saw must have had 422/58 in it, not the 423/C1 we see > now. So what needs to be explained is why what Mason is looking at now > is different from what the slave saw ten days ago. So the slave did see a problem ten days ago, though I take your point that the problem we see now may not be the as it was back then. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
