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-08T18:39:45Z
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
On Tue, Apr 08, 2025 at 01:42:20PM -0400, Tom Lane wrote: > Nathan Bossart <nathandbossart@gmail.com> writes: >> Unless I'm missing something, we don't seem to have had any dependency >> handling before commit 12a53c7. Was that broken before we moved to SQL >> commands? > > Sounds like it :-( Huh. Sure enough, it seems to be lost during an upgrade from 9.6 to 10. v9.6: postgres=# select lo_from_bytea(1234, '1234'); lo_from_bytea --------------- 1234 (1 row) postgres=# create role bob; CREATE ROLE postgres=# grant select on large object 1234 to bob; GRANT postgres=# drop role bob; ERROR: role "bob" cannot be dropped because some objects depend on it DETAIL: privileges for large object 1234 v10 (upgraded from v9.6): postgres=# select lo_get(1234); lo_get ------------ \x31323334 (1 row) postgres=# drop role bob; DROP ROLE If I then try to upgrade that database to v17, it fails like this: pg_restore: from TOC entry 2422; 0 0 ACL LARGE OBJECT 1234 nathan pg_restore: error: could not execute query: ERROR: role "16384" does not exist Command was: GRANT SELECT ON LARGE OBJECT 1234 TO "16384"; I've also verified that the dependency information is carried over in upgrades to later versions (AFAICT all the supported ones). -- nathan