I will provide some answers tomorrow, but I don't have access now. It's a law enforcement agency in another state and
theofficer I work with will be in Sunday. The original computer's postgres server is stopped, and port forwarding
wasn'tchanged yet so I don't have access to the new computer where the server is running. I have no access to the files
themselvesunless he's there and let's me in.
Thanks. Keep tuned.
John
On Sat, 12 Jun 2010 15:59:06 -0700, Adrian Klaver wrote:
>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.klaver@gmail.com