On 13/06/10 02:34, Adrian Klaver wrote: >> Question: Is it possible that there's corruption in the database which is >> being incorrectly reported as "Permission denied"? It's certainly not impossible. It'd really help if Pg would print more details from Windows' error reporting - GetLastError() etc - in cases like this. In fact, some searching reveals complaints about just that as far back as mid-2008 related to the exact error you're encountering. Anyway: When you moved the data dir over, did you reset all the permissions on it so that it is owned by the "postgres" user on the new machine? Applying those permissions recursively? Does the file that PostgreSQL is complaining about actually exist? Is it always the same 'xxx/xxx'? Is it an index or a relation? You can find out using the Pg catalogs: http://www.postgresql.org/docs/current/static/storage-file-layout.html http://www.postgresql.org/docs/current/static/catalog-pg-class.html ... from which you'll see that of: base/xxx/yyy 'base/xxx' is the prefix for your database, and within that 'yyy' is the oid of the table, so you can find out some details about it with the following SQL: \x select * from pg_class where oid = yyy; Does the table/index name reported by that query match one that is actually used in the problem query? What is it? Please post the full output of the above query. If it's an index, does REINDEXing your database help? If it's a relation, does CLUSTERing that relation succeed? Help? >> Is this a random event? A bug? Advice please on what to do next. It's really, really hard to know, especially with the involvement of elderly OSes and antivirus software. Could it be a Pg bug causing this? Of course. But it's really, really hard to know what, when, and how, especially with no access to the machines and data in question. Please keep a copy of this damaged cluster around, even if you decide to go ahead and rebuild the cluster. Now that its on a known-working platform and the issue has been shown not to be proximately* caused by antivirus software, it'd be preferable to find out what's actually going on here. That will be impossible without the damaged cluster. (* ie if the AV software was involved, it was to damage something that stays damaged after the AV is taken out of the picture) -- Craig Ringer -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
