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

On Saturday 12 June 2010 12:59:18 pm John T. Dow wrote:

I am CC'ing the list so more eyes can follow this.

> >
> >Some more questions.
> >What is the relation that is having the permissions issue?
> >Are the permissions on that file different from the others in the base
> > directory tree?
> >What is the 'certain text'?
> >What are the 'certain fields' and do they have any functions running on
> > them?
> >
> >
> >
> >--
> >Adrian Klaver
>
> The actual message is: could not open relation base/16384/16642: Permission
> denied.
>
> I presume that the actual file names are not important as they change from
> time to time?

They may or may not depending on what type of relation they are and the type of
operation done to them. I should have been more specific. What is 16642?
SELECT relname,relkind from pg_class where relfilenode=16642 should provide an
answer.

>
> No, we have not diddled with the permissions. All files inherit their
> permissions from "data".

The question is really not whether you changed the permissions, but whether they
have been changed? Hate to be anal about this, but have you actually looked at
the permissions for that file or are you assuming inheritance of permissions?

>
> The text I've been using for test purposes is a plain ascii version of the
> US Constitution. It's about 50K, nothing special about it. Just a plain
> text file I had on hand.

But large enough to invoke TOASTing the value. See here for more info:
http://www.postgresql.org/docs/8.4/interactive/storage-toast.html

>
> The fields where we noticed it at a couple jTextArea fields in a Java
> application. They are defined as varchar. There is nothing special about
> these fields. No functions, etc. They are fields to hold plain English
> text. Data is normally entered by someone typing it in. (One example is a
> police officer typing in his report of an arrest he's made. After he types
> it in, it's printed and signed and becomes a legal document.) There is a
> similar field in each of three tables: two of the three produced this error
> when we pasted in the text, but the third one had no problem. We also
> pasted the text into some other fields and got the problem. However, except
> for these fields and this text, we have load many fields with data from a
> legacy system and have typed in information into many fields and have had
> no problems. That is to say, the problem is rare, although it has happened
> every time we've pasted that text into those two fields.

Might be worth showing us the complete schema for those tables. Just to be
clear, which describes the problem:
A)100% reproducible by putting the above text into either of the two fields
OR
B) Rare but when it happens it involves the above text and these two fields.

>
> John

--
Adrian Klaver
adrian(dot)klaver(at)gmail(dot)com