Re: Horribly slow pg_upgrade performance with many Large Objects

Nathan Bossart <nathandbossart@gmail.com>

From: Nathan Bossart <nathandbossart@gmail.com>

To: Tom Lane <tgl@sss.pgh.pa.us>

Cc: Hannu Krosing <hannuk@google.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>

Date: 2025-04-09T17:16:44Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

pg_upgrade: Use COPY for large object metadata.
- 161a3e8b682e 19 (unreleased) landed
pg_dump: Fix object-type sort priority for large objects.
- fb6c860bbd1f 19 (unreleased) landed
- e43fae199e50 17.6 landed
- 36026b0fe3ab 18.0 landed
pg_upgrade: Mention that we preserve database OIDs in a comment.
- e2665efd0f4d 18.0 landed
pg_upgrade: Preserve database OIDs.
- aa01051418f1 15.0 cited
Fix pg_upgrade for oid removal.
- 12a53c732ced 12.0 cited

Attachments

v1-0001-Mention-that-we-preserve-database-OIDs-in-pg_upgr.patch (text/plain)

On Tue, Apr 08, 2025 at 01:51:22PM -0400, Tom Lane wrote:
> Nathan Bossart <nathandbossart@gmail.com> writes:
>> On Tue, Apr 08, 2025 at 01:36:58PM -0400, Tom Lane wrote:
>>> Hmm ... one annoying thing for this project is that AFAICS pg_upgrade
>>> does *not* preserve database OIDs, which is problematic for using
>>> COPY to load pg_shdepend rows.
> 
>> I think it does; see commit aa01051.
> 
> Ah --- I thought I remembered something having been done about that,
> but I failed to find it because I was looking in pg_upgrade not
> pg_dump.  Too bad aa01051 didn't update the comment at the top of
> pg_upgrade.c.

I'll apply the attached patch to fix the comment shortly.

-- 
nathan