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-11T21:00:51Z
Lists: pgsql-hackers

Attachments

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

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.