Thomas Eckestad <thomas.eckes...@gmail.com> writes: > 2012/11/1 Tom Lane <t...@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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs