Thomas Eckestad <thomas.eckestad@gmail.com> writes:
> 2012/11/1 Tom Lane <tgl@sss.pgh.pa.us>
>> That is extremely peculiar --- AFAICS, 9.1 should never assign a
>> relfilenode of 12693.
> I am afraid that I can not guarantee that the example that I posted
> (global/12693) was triggered with version 9.1.6. It might be for 9.0.x or
> 9.1.x, if that makes a difference. I am sure though that global/12589 was
> triggered using 9.1.5 (upgraded to 9.1.6 just a few days ago).
I realized that these numbers are actually quite a lot more
platform-specific than I'd been thinking, since in 9.1 they will vary
depending on how many OIDs got consumed for pg_collation entries,
and that will depend not only on your operating system but how many
locales you've seen fit to install. So I'm probably wrong to have
guessed that this might represent a mistaken access to a relfilenode
that never should have existed.
What I'd suggest doing is monitoring the output of this query:
select relname, pg_relation_filenode(oid) from pg_class where relisshared;
which will tell you what filenames *ought* to be present in
$PGDATA/global, and then when something goes missing it'll be possible
to figure out which table or index it was. That might provide at least
the first clue what's wrong.
regards, tom lane
