Hi Greg! Thank you for your immediate response. I cannot tell you the xfs_repair files that were mangled but I did the repair on an lvm snapshot. the files were not listed in 'select * from pg_class'. Might not be THE source for inodes needed by the cluster?
I agree, it does not really sonud like a pg bug, rather a pg corruption due to whatever else. I cannot imagine xfs / raid / lsi combination being the problem. I rather guess that some ram might have been corrupted. I am moving the cluster to another hardware and hope to have better insight there. I am sorry for being partially vague. I cannot really grasp the problem myself, this is why my description might be lacking detail. I will cross-post to 'general' thx,k On Mon, Jul 29, 2013 at 11:38 PM, Greg Stark <st...@mit.edu> wrote: > On Mon, Jul 29, 2013 at 10:19 PM, Klaus Ita <kl...@worstofall.com> wrote: > > My feeling is, that 'something' got confused with hot-standby and > > wal_archiving leading to this situation, that seems to be partially xfs > > caused?????? xfs_repair mentionned some missing files, that pg did not > > expect to have (maybe truncated tables??). > > This doesn't sound like a problem with wal archiving or hot standby. > It doesn't sound like a postgres bug at all. It sounds like your > filesystem deleted some files that Postgres needs. The pg clog > contains critical data that you're not going to be able to get by > without. > > I suggest posting to pgsql-general and include more information to > help people help you. You say xfs_repair mentioned some missing files > but don't include the actual error messages for example. > > > -- > greg >
