Re: Horribly slow pg_upgrade performance with many Large Objects

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

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

To: Nathan Bossart <nathandbossart@gmail.com>

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

Date: 2025-07-14T17:28:03Z

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

Nathan Bossart <nathandbossart@gmail.com> writes:
> Here is what I have staged for commit, which (barring feedback or
> objections) I am planning to do towards the end of the week.

Is it intentional that this does

+#include "catalog/pg_largeobject_metadata.h"
+#include "catalog/pg_shdepend.h"

rather than including the corresponding *_d.h headers?
If so, why?  Our normal coding convention is that frontend
code should only include catalog *_d.h files, since the main
headers might contain frontend-unfriendly declarations.
If there is something we need to expose in these catalogs'
*_d.h headers, we should probably do that.

			regards, tom lane