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