Horton

Re: pg_upgrade: transfer pg_largeobject_metadata's files when possible

Nathan Bossart <nathandbossart@gmail.com>

View thread View on postgr.es
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>
Date: 2026-02-08T22:00:40Z
Lists: 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

Commits

  1. pg_upgrade: Use COPY for LO metadata for upgrades from < v12.

  2. pg_upgrade: Fix handling of pg_largeobject_metadata.

  3. pg_upgrade: Transfer pg_largeobject_metadata's files when possible.

  4. Rearrange pg_dump's handling of large objects for better efficiency.

  5. Expand AclMode to 64 bits

  6. Fix pg_upgrade for oid removal.