Date: Sun, 8 Feb 2026 16:00:40 -0600
From: Nathan Bossart <nathandbossart@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Michael Paquier <michael@paquier.xyz>, Tom Lane <tgl@sss.pgh.pa.us>,
	Nitin Motiani <nitinmotiani@google.com>,
	Hannu Krosing <hannuk@google.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: pg_upgrade: transfer pg_largeobject_metadata's files when
 possible
Message-ID: <aYkHiDrBRz2snwyn@nathan>
References: <aYNuhbXkM5h8Zcsu@nathan>
 <aYOnT5EqAqI3ooBO@nathan>
 <qfp7z4c3m6bw53oky33halcdhomiijod6segzrhf757ijjvapr@e5rf4u5wnfmu>
 <aYTVAFTPelebVl6W@nathan>
 <nt56moqkh6yoerzw5cml6qu7m4mxu65vqtgdt3nbm5mhpg5hqt@4s5oa3sqhzub>
 <aYTwC8V50rPgw6GE@nathan>
 <t3zu4hyzwqws4puaqd2lhdlw7yp2ckgswuaaizmfi6seto3x4w@5exxg3kazkos>
 <aYT95PGdMvHHzwsP@nathan>
 <aYUL01ZYpDBaZ7qN@nathan>
 <jaqwqwwiy57bhg36jru4mvjznzemrhgobyynpqvyp573m7h3rt@2kpgm5sfkbyy>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <jaqwqwwiy57bhg36jru4mvjznzemrhgobyynpqvyp573m7h3rt@2kpgm5sfkbyy>
Archived-At: <https://www.postgresql.org/message-id/aYkHiDrBRz2snwyn%40nathan>
Precedence: bulk

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