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 <stark@mit.edu> wrote:
> On Mon, Jul 29, 2013 at 10:19 PM, Klaus Ita <klaus@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
>
