Re: Horribly slow pg_upgrade performance with many Large Objects - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: Horribly slow pg_upgrade performance with many Large Objects
Date
Msg-id Z_VTucTiS01p-d6z@nathan
Whole thread Raw
In response to Re: Horribly slow pg_upgrade performance with many Large Objects  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Horribly slow pg_upgrade performance with many Large Objects
List pgsql-hackers
On Tue, Apr 08, 2025 at 12:37:43PM -0400, Tom Lane wrote:
> Hannu Krosing <hannuk@google.com> writes:
>> I think we do preserve role oids
> 
> Oh ... I'd been looking for mentions of "role" in
> pg_upgrade_support.c, but what I should have looked for was
> "pg_authid".  So yeah, we do preserve role OIDs, and maybe that's
> enough to make this workable, at least with source versions that
> share the same rules for what goes into pg_largeobject_metadata and
> pg_shdepend.  It's not something I'd risk back-patching though.

I do think it's worth considering going back to copying
pg_largobject_metadata's files for upgrades from v16 and newer.  That
sounds restrictive at the moment, but it'll mean that all but one supported
major version can copy the files during upgrade to v19.  I'll admit I'm a
tad worried about having to go back to copying via SQL commands in the
future and re-regressing things (leading to unpredictable differences in
upgrade downtime), but I'm not sure that's a great reason to withhold this
optimization.

Of course, I wouldn't be opposed to optimizing the SQL command strategy,
too, but I suspect that won't compare to copying the files.

-- 
nathan



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER
Next
From: Jacob Champion
Date:
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER