Re: pg_upgrade: transfer pg_largeobject_metadata's files when possible - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: pg_upgrade: transfer pg_largeobject_metadata's files when possible
Date
Msg-id aYzuAz_ITUpd9ZvH@nathan
Whole thread Raw
In response to Re: pg_upgrade: transfer pg_largeobject_metadata's files when possible  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: pg_upgrade: transfer pg_largeobject_metadata's files when possible
Re: pg_upgrade: transfer pg_largeobject_metadata's files when possible
List pgsql-hackers
On Sun, Feb 08, 2026 at 04:00:40PM -0600, Nathan Bossart wrote:
> On Sun, Feb 08, 2026 at 04:26:41PM -0500, Andres Freund wrote:
>> On 2026-02-05 15:29:55 -0600, Nathan Bossart wrote:
>>> +     * commands.  We can only do this for upgrades from v12 and newer; in
>>> +     * older versions, pg_largeobject_metadata was created WITH OIDS, so the
>>> +     * OID column is hidden and won't be dumped.
>>>       */
>> 
>> It's not really related to this change, but what is that WITH OIDS bit about?
>> Sure, they aren't shown by default, but all it takes to change that is to
>> explicitly add the output column? I'm not saying we have to do that, I just
>> don't understand the reasoning as written here.
> 
> IIRC the issue is that getTableAttrs() won't pick up the OID column on
> older versions.  It might be easy to fix that by adjusting its query for
> binary upgrades from <v12.  That could be worth doing, if for no other
> reason than to simplify some of the pg_dump code.  I'll make a note of it.

This was a little more painful than I expected, but this seems to be what
is required to allow COPY-ing pg_largeobject_metadata during binary
upgrades from < v12.

-- 
nathan

Attachment

pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: Add CREATE SCHEMA ... LIKE support
Next
From: Alexandre Felipe
Date:
Subject: SLOPE - Planner optimizations on monotonic expressions.