Re: Auto-delete large objects when referencing row is deleted

Hi.
> <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> wrote:

> (It would be a rare case, but) A large object might be referenced
> by two or more rows because LO interface is split into two steps;
> allocating oid and storing data for it. The oid could be stored in
> two or more places and auto deletion would break such usecases.

Indeed. We have to check the references on garbage collecting.
For this reason, my plan B "Merge contrib/vacumelo to VACUUM" is
easier to implement.

> BTW, bytea and TOASTing would works perfectly as you expected.
> Why don't you use bytea instead of large objects? In other words,
> what you want actually is not LO improvement but efficient TOASTing, no?

First of all, what I want is to contribute to PostgreSQL community by
writing patches.
And picked this issue up from TODO list.
So if there's no need to do about this issue, I will pick up another one :-)

I've checked some articles about "Oid large objects vs bytea".
If I understand them correctly, I think
both large objects and bytea are useful for different situations.
Neither of them are obsolete.

Is there no need to do about this issue?

Cheers.

==========================================================
the negative points of bytea:
memory hungry.
slower than large objects.
1GB limitation.

the negative points of large objects:
ghost problem (no auto-delete).
unable to store number of objects greater than 2^32.
==========================================================

-----
Taro Minowa(Higepon)

Cybozu Labs, Inc.

http://www.monaos.org/
http://code.google.com/p/mosh-scheme/

On Wed, Apr 8, 2009 at 1:15 PM, Itagaki Takahiro
<itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> wrote:
>
> higepon <higepon(at)gmail(dot)com> wrote:
>
>> As a user of database, I think contrib/lo is not the best way.
>> Because it's not a part of core PostgreSQL, users may forget to use them.
>> Or it is a little messy to use.
>> So I think we need to implement *Auto* delete functionality in PostgreSQL core.
>
> (It would be a rare case, but) A large object might be referenced
> by two or more rows because LO interface is split into two steps;
> allocating oid and storing data for it. The oid could be stored in
> two or more places and auto deletion would break such usecases.
>
> BTW, bytea and TOASTing would works perfectly as you expected.
> Why don't you use bytea instead of large objects? In other words,
> what you want actually is not LO improvement but efficient TOASTing, no?
>
> Regards,
> ---
> ITAGAKI Takahiro
> NTT Open Source Software Center
>
>
>