On 9 January 2012 12:40, Stefan Keller <sfkeller@xxxxxxxxx> wrote: > There's an important principle that the code which "allocates" > resources is also responsible to release it. That's one resource allocation model, yes. The other common model is that resources are freed when there are no remaining references to them, i.e. a GC model. > AFAIK in this case it's JDBC which choses to use LO (which creates > pg_largeobjects entries) and it's therefore also JDBC which has to > clean up. If the application calls LargeObjectManager.create() then it's also responsible for eventually calling LargeObjectManager.unlink(). If you're using JDBC's Blob API, there's no API there to tell the driver to actually delete the underlying data (there is Blob.free(), but that appears to just be about freeing local resources, not the underlying storage). As a LO is independent storage that might have multiple references to it (the OID might be stored in many places), without explicit deletion you need a GC mechanism to collect unreferenced LOs eventually - that's what vacuumlo etc are doing. What do you suggest that the driver does differently here? (Perhaps we could do something like interpret Blob.truncate(0) as "delete the blob right now" - but is that what Hibernate actually does?) (Much of this is the whole LO vs. bytea argument all over again. If you want to store data with a lifetime that's the same as the row it's embedded in, then bytea is a much better mapping) Oliver -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
