Обсуждение: vacuumlo.
I sent the email below to the creator of contrib/vacuumlo/ with no reply just yet. Is it possible to get his code included in the main vacuumdb program for support to vacuum orphaned large objects? Or... Any suggestions, what do people think? Thanks. ---------- Forwarded message ---------- Date: Tue, 24 Jul 2001 09:45:01 +1000 (EST) From: Grant <grant@conprojan.com.au> To: peter@retep.org.uk Subject: vacuumlo. G'day, I've recently discovered that LO's do not get deleted when a record referencing that OID is removed. I'm assuming you created the program and do you think it is possible to get this included as an argument for vacuumdb? vacuumdb -o <db> Or something along those lines so scanning for orphan large objects could be done from the main vacuum binary? What do you think? Thanks.
Grant <grant@conprojan.com.au> writes:
> Is it possible to get [vacuumlo] included in the main vacuumdb program for
> support to vacuum orphaned large objects?
Hmm. I'm not convinced that vacuumlo is ready for prime time...
in particular, how safe is it in the presence of concurrent
transactions that might be adding or removing LOs?
regards, tom lane
> > Is it possible to get [vacuumlo] included in the main vacuumdb program for > > support to vacuum orphaned large objects? > > Hmm. I'm not convinced that vacuumlo is ready for prime time... > in particular, how safe is it in the presence of concurrent > transactions that might be adding or removing LOs? I see large objects for each database are stored in pg_largeobject referenced by the loid. So when I delete a file from a table containing an oid type I have to make sure to delete the matching row(s) from pg_largeobject. Can you see a scenario where a programmer would forget to delete the data from pg_largeobject and the database becoming very large filled with orphaned large objects? Or am I on the wrong track?
Grant <grant@conprojan.com.au> writes:
> Can you see a scenario where a programmer would forget to delete the
> data from pg_largeobject and the database becoming very large filled
> with orphaned large objects?
Sure. My point wasn't that the functionality isn't needed, it's that
I'm not sure vacuumlo does it well enough to be ready to promote to
the status of mainstream code. It needs more review and testing before
we can move it out of /contrib.
regards, tom lane
Tom Lane wrote: > > Grant <grant@conprojan.com.au> writes: > > Can you see a scenario where a programmer would forget to delete the > > data from pg_largeobject and the database becoming very large filled > > with orphaned large objects? > > Sure. My point wasn't that the functionality isn't needed, it's that > I'm not sure vacuumlo does it well enough to be ready to promote to > the status of mainstream code. It needs more review and testing before > we can move it out of /contrib. > IIRC vacuumlo doesn't take the type lo(see contrib/lo) into account. I'm suspicious if vacuumlo is reliable. regards, Hiroshi Inoue
> > > Can you see a scenario where a programmer would forget to delete the > > > data from pg_largeobject and the database becoming very large filled > > > with orphaned large objects? > > > > Sure. My point wasn't that the functionality isn't needed, it's that > > I'm not sure vacuumlo does it well enough to be ready to promote to > > the status of mainstream code. It needs more review and testing before > > we can move it out of /contrib. > > > > IIRC vacuumlo doesn't take the type lo(see contrib/lo) into > account. I'm suspicious if vacuumlo is reliable. This was my round about way of asking if something to combat this issue can be placed in the to do list. :) Thanks.
> > > > Can you see a scenario where a programmer would forget to delete the > > > > data from pg_largeobject and the database becoming very large filled > > > > with orphaned large objects? > > > > > > Sure. My point wasn't that the functionality isn't needed, it's that > > > I'm not sure vacuumlo does it well enough to be ready to promote to > > > the status of mainstream code. It needs more review and testing before > > > we can move it out of /contrib. > > > > > > > IIRC vacuumlo doesn't take the type lo(see contrib/lo) into > > account. I'm suspicious if vacuumlo is reliable. > > This was my round about way of asking if something to combat this issue > can be placed in the to do list. :) Added to TODO: * Improve vacuum of large objects (/contrib/vacuumlo) -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian wrote: > > > > > > Can you see a scenario where a programmer would forget to delete the > > > > > data from pg_largeobject and the database becoming very large filled > > > > > with orphaned large objects? > > > > > > > > Sure. My point wasn't that the functionality isn't needed, it's that > > > > I'm not sure vacuumlo does it well enough to be ready to promote to > > > > the status of mainstream code. It needs more review and testing before > > > > we can move it out of /contrib. > > > > > > > > > > IIRC vacuumlo doesn't take the type lo(see contrib/lo) into > > > account. I'm suspicious if vacuumlo is reliable. > > > > This was my round about way of asking if something to combat this issue > > can be placed in the to do list. :) > > Added to TODO: > > * Improve vacuum of large objects (/contrib/vacuumlo) > Is it possible for vacuumlo to be moved out of /contrib ? As far as I see, there's no perfect solution for vacuumlo. regards, Hiroshi Inoue
> > > > IIRC vacuumlo doesn't take the type lo(see contrib/lo) into > > > > account. I'm suspicious if vacuumlo is reliable. > > > > > > This was my round about way of asking if something to combat this issue > > > can be placed in the to do list. :) > > > > Added to TODO: > > > > * Improve vacuum of large objects (/contrib/vacuumlo) > > > > Is it possible for vacuumlo to be moved out of /contrib ? > As far as I see, there's no perfect solution for vacuumlo. Not sure myself. Let's see what others say. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026