From: | "Carlos J(dot) Garcia Orellana" <carlos(at)nernet(dot)unex(dot)es> |
---|---|
To: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Problems with lo_unlink |
Date: | 1998-08-30 17:15:29 |
Message-ID: | 000601bdd439$ca55ffe0$8218319e@seminario1.unex.es |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello,
Is it 'lo_unlink' a secure function?.
I've problems with it. I'm using a database with large objects (images) and
I've problems
with that, this problems are:
* Sometimes, when I tried to export a large object with SQL command:
SELECT lo_export(oid '65570', '/tmp/myfile')
the backend says to me:
ERROR: xinx65560 is a index relation.
I see that the oids of 'xinv65570' and 'xinx65560' are the same. So, when I
say to postgres that I want to export the oid 65570, it thinks that I want
the index xinx65560.
I fix this problem using the function 'heap_openr' in 'inv_open' instead of
'heap_open'. With this change, I always open a 'xinvXXXX'. I've made this
change in 'inv_destroy', too.
* The other problem is related the function 'lo_unlink'. I think that when I
destroy a large object, I destroy its index, then, if I do:
SELECT lo_unlink( int4 '65560')
I'm sure that I destroy the object 'xinv65560' (because I've changed the
'heap_open' by 'heap_openr'), and if the backend attempts to destroy the
index (whose oid is 65570), and as it's the same oid that the large object
'xinv65570' , it's possible the backend destroy that large object instead of
the index.
Well, my questions are:
* Is this true?, Is it like I think?.
* Are there some solutions for these problems?
Thanks.
(Please answer to me at: carlos(at)nernet(dot)unex(dot)es)
Carlos J. Garcia Orellana.
Universidad de Extramadura - Badajoz
SPAIN
From | Date | Subject | |
---|---|---|---|
Next Message | Peter T Mount | 1998-08-30 17:44:40 | Re: [HACKERS] pgindent for Monday |
Previous Message | Tom Lane | 1998-08-30 16:50:55 | Re: [HACKERS] flock patch breaks things here |