Thread: Testing lo_unlink() in psql

I'm running postgres 8.1.8 on redhat.

I have a very large table that contains an OID that refers to a large
object.  I have a rule defined that calls lo_unlink() on a delete.  I
seem to get a successful return status on the delete, but my total disk
space used does not seem to shrink.

I've run "VACUUM ANALYZE" on the table after the delete and have the
same behavior.  Do I need to run a "VACUUM FULL" to get the space back
after an lo_unlink()?

Is there some other reason I'm not reclaiming disk space after an
lo_unlink()?

Also, is there any way to determine the actual filename that the OID
references?  I'd like to be able to do an "ls -l <filename>" before and
after the lo_unlink() command to confirm that the file has been removed.

I can't really do lo_list from psql because the table is > 2.5 million
rows. 

Thanks,

Mike

"Michael Goldner" <MGoldner@agmednet.com> writes:
> I've run "VACUUM ANALYZE" on the table after the delete and have the
> same behavior.  Do I need to run a "VACUUM FULL" to get the space back
> after an lo_unlink()?

Vacuuming the table isn't gonna help much, because all that reclaims
is your table row, not the space occupied by the large object.  Large
objects live in pg_largeobject, and you need to be vacuuming *that*
on a regular basis if you do much deleting or updating of large objects.

> Also, is there any way to determine the actual filename that the OID
> references?

You appear to be seriously confused about how large objects are
stored.  See
http://www.postgresql.org/docs/8.1/static/largeobjects.html
http://www.postgresql.org/docs/8.1/static/catalog-pg-largeobject.html

            regards, tom lane