I will provide some answers tomorrow, but I don't have access now. It's a law enforcement agency in another state and the officer I work with will be in Sunday. The original computer's postgres server is stopped, and port forwarding wasn't changed yet so I don't have access to the new computer where the server is running. I have no access to the files themselves unless 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@xxxxxxxxx -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
