Re: Vacuumlo improvements

From: Sami Imseih <samimseih(at)gmail(dot)com>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Shawn McCoy <shawn(dot)the(dot)mccoy(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Vacuumlo improvements
Date: 2026-05-15 19:36:22
Message-ID: CAA5RZ0sF_p-ZE6LdVgzPr=9C32i2p1Pu7uxAPCV22-qh4tFh_Q@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > Commit 64c604898e added the note about domains to the docs. Unfortunately,
> > neither that nor the corresponding thread [0] offer any clues as to why
> > vacuumlo doesn't resolve domains. The commit history for vacuumlo has been
> > pretty quiet for a long time, so maybe it's just been overlooked.
>
> It seems to be relatively easy to teach vacuumlo to handle domains over
> oid. Note that you need a recursive query because you can have domains
> over domains. Please test it out.

I think there is value in expanding the vacuumlo search capability for
LOs and OIDs.
We can also detect LOs and OIDs stored in composite types, or OID[] and LO[].
All these are detectable from the catalog.

The one complexity will be we will need vacuumlo to generate more complex
expressions for deleting the data.

DELETE FROM t WHERE lo IN (SELECT ("data")."lo_ref" FROM t_lo);

But, this will be more comprehensive and can cover all potential ways
an OID or LO can be used.

What do you think?

> Please test it out. I noticed that vacuumlo's tests are
> pretty sad, so this might be a good opportunity to change that.

More tests will be needed for sure.

But with all this done, I am not sure how much this moves the needle. It may
somewhat, but it's hard to tell how much.
I know I have seen users store LO references in text or other types,
so I think we still need the documentation enhancement to call out
the "data loss" potential.

I also think it will be good for the LO documentation [1] to nudge the users
to think about using the LO extension, as is done with the vacuumlo [2]
documentation.

[1] https://www.postgresql.org/docs/current/lo.html
[2] https://www.postgresql.org/docs/current/vacuumlo.html

--
Sami

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2026-05-15 19:54:10 Re: Order of tables dumped by pg_dump
Previous Message Isaac Morland 2026-05-15 18:36:58 Order of tables dumped by pg_dump