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 aYkHiDrBRz2snwyn@nathan
Whole thread Raw
In response to Re: pg_upgrade: transfer pg_largeobject_metadata's files when possible  (Andres Freund <andres@anarazel.de>)
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: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.

> The improvements in pg_upgrade time and memory in a cluster with 50M LOs [1]
> are really quite impressive, even if upgrading from < 16. It's rare to improve
> memory usage by several orders of magnitude.

Nice!

-- 
nathan



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: pg_upgrade: transfer pg_largeobject_metadata's files when possible
Next
From: "Jelte Fennema-Nio"
Date:
Subject: Re: Add GoAway protocol message for graceful but fast server shutdown/switchover