Re: Re: Error on Windows server could not open relation base/xxx/xxx Permission denied

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