I'm not sure if this is an XFS problem, or Postgres. There's enough suspicious evidence that it's too hard to say.
Today, I get an interesting issue raised whereby a reasonably simple query fails on a system that does take successful pg_dumps regularly. To make a short story shorter, I end up with the following situation on an index relation file: $ sha1sum 16587.8 pg_internal.init 4a0f94285c182b67175d6a68669c6b9fd46fa11e 16587.8 4a0f94285c182b67175d6a68669c6b9fd46fa11e pg_internal.init And, even more interestingly, $ stat 16587.8 pg_internal.init File: `16587.8' Size: 98532 Blocks: 200 IO Block: 4096 regular file Device: fe00h/65024d Inode: 1073741952 Links: 1 Access: (0600/-rw-------) Uid: ( 107/postgres) Gid: ( 115/postgres) Access: 2011-12-14 23:35:35.630043643 +0000 Modify: 2011-12-14 23:35:35.630043643 +0000 Change: 2011-12-14 23:35:35.630043643 +0000 File: `pg_internal.init' Size: 98532 Blocks: 200 IO Block: 4096 regular file Device: fe00h/65024d Inode: 1073741952 Links: 1 Access: (0600/-rw-------) Uid: ( 107/postgres) Gid: ( 115/postgres) Access: 2011-12-14 23:35:35.630043643 +0000 Modify: 2011-12-14 23:35:35.630043643 +0000 Change: 2011-12-14 23:35:35.630043643 +0000 Most notably, the inode numbers are the same. At first, I thought this was a file descriptor race in PG, but then I noticed the file system only reports *one* link: that doesn't look like a valid state for XFS. Should I raise this on their mailing list, and would pgsql-hackers like to know more about this? Also, consider this an advisory, as this was found on a vanilla Ubuntu Lucid 10.04 machine. As such, I do think this probably could have happened to a non-index relation file. This database has had uptime since mid-December, and that inode seems to have been modified at the time of the last reboot. The database was born in October via point-in-time recovery. ...Happy New Year! -- fdr -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers