Date: Fri, 15 May 2026 15:29:39 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: Sami Imseih <samimseih@gmail.com>
Cc: Shawn McCoy <shawn.the.mccoy@gmail.com>, pgsql-hackers@postgresql.org
Subject: Re: Vacuumlo improvements
Message-ID: <ageCM0exH2mKeZBT@nathan>
References: 
 <CALsgZNAM=AYK-9ZLR7Z0YLx6Lyx5aSrjjse3T+FmsJ=jTvfhDQ@mail.gmail.com>
 <agPpPyLs-61qFw88@nathan>
 <agU9JPim3XNwRJ4b@nathan>
 <CAA5RZ0sF_p-ZE6LdVgzPr=9C32i2p1Pu7uxAPCV22-qh4tFh_Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAA5RZ0sF_p-ZE6LdVgzPr=9C32i2p1Pu7uxAPCV22-qh4tFh_Q@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/ageCM0exH2mKeZBT%40nathan>
Precedence: bulk

On Fri, May 15, 2026 at 02:36:22PM -0500, Sami Imseih wrote:
> 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?

It seems worth exploring.

> 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.

Yeah, I think we'll have to do some combination of 1) improving vacuumlo,
2) improving the documentation to warn users about things vacuumlo doesn't
catch, and 3) improving the documentation to nudge users toward the lo
extension.. 

-- 
nathan