Michael Brusser <michael@synchronicity.com> 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