Thread: OID type creates files that don't go away

OID type creates files that don't go away

From
"David Wall"
Date:
I've created several blobs using the OID type.  I note that the database
stores the "oid" number that represents two files on disk, such as xinv21281
and xinx21281 with the oid in the database showing up as 21281 via a SELECT.

But, I deleted a row that contained this oid, and the two 'x' files are
still on disk.  I then ran a VACUUM, saw that 1 record was reaped, but the
two 'x' files remain.  Are these 'x' files going to be reused in some
manner, or is this a bug that keeps them around despite the fact that the
database row for it has been removed?

David



Re: OID type creates files that don't go away

From
Stephan Szabo
Date:
I'm guessing you're using the Large Object interface?  AFAIR, The LO
interface doesn't automatically clean up after you so you have to make
triggers as necessary to deal with deletes.

On Tue, 23 Jan 2001, David Wall wrote:

> I've created several blobs using the OID type.  I note that the database
> stores the "oid" number that represents two files on disk, such as xinv21281
> and xinx21281 with the oid in the database showing up as 21281 via a SELECT.
>
> But, I deleted a row that contained this oid, and the two 'x' files are
> still on disk.  I then ran a VACUUM, saw that 1 record was reaped, but the
> two 'x' files remain.  Are these 'x' files going to be reused in some
> manner, or is this a bug that keeps them around despite the fact that the
> database row for it has been removed?