Michael Brusser <[EMAIL PROTECTED]> writes: > It looks that "No such file or directory" followed by the abort signal > resulted from manually removing logs. pg_resetxlog took care of this, > but other problems persisted.
> pg_dump: ERROR: XLogFlush: request 0/A971020 is not satisfied --- > flushed only to 0/5000050 ... lost synchronization with server, resetting > connection Okay, you have a page with an LSN of A971020 which is past end of XLOG (5000050). You may have created this problem for yourself by doing pg_resetxlog with poorly chosen parameters. You could try redoing it with an XLOG start address larger than that (I'd suggest quite a bit larger, since there's no reason to believe that this is the latest-modified page in the whole DB). Theory B is that this particular page is corrupted and the LSN is just trash. But that seems less likely, since 7.3.4 has checks that test the other page header fields fairly well. Usually all the header fields are garbage if any are. > drop table fails: > drop table note_links_aux; > ERROR: getObjectDescription: Rule 17019 does not exist This looks like plain old corruption ... > Out next release is using v 7.3.4. (maybe it's not too late to upgrade) > Would v. 7.3.6 provide more protection against problems like this? Read the release notes. But I can't think of any reason to take the time to update and not go all the way to the latest dot-release in your branch. It's not going to be any harder, and it will get you more bug fixes. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])