Re: pg_upgrade: transfer pg_largeobject_metadata's files when possible
Nathan Bossart <nathandbossart@gmail.com>
From: Nathan Bossart <nathandbossart@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: 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: 2025-09-02T14:43:40Z
Lists: pgsql-hackers
On Mon, Sep 01, 2025 at 03:19:46PM +0900, Michael Paquier wrote: > I highly doubt that there are a lot of comments assigned to LOs, so > these numbers are pretty cool IMO. Security labels are a pain to test > in the upgrade path, or test_dummy_label could be extended with a new > TAP test and a pg_upgrade command.. There is some coverage with > comments on LOs in src/bin/pg_dump's 002, so that would be enough for > the comment part, at least. Do you think a new pg_upgrade test for security labels is worth the trouble? It seems doable, but it'd be an awfully expensive test for this. On the other hand, I'm not sure there's any coverage for pg_upgrade with security labels, so perhaps this is a good time to establish some tests. > - /* > - * pg_largeobject > - */ > if (fout->remoteVersion >= 90300) > appendPQExpBuffer(loFrozenQry, "SELECT relfrozenxid, relminmxid, relfilenode, oid\n" > "FROM pg_catalog.pg_class\n" > - "WHERE oid IN (%u, %u);\n", > - LargeObjectRelationId, LargeObjectLOidPNIndexId); > + "WHERE oid IN (%u, %u, %u, %u);\n", > + LargeObjectRelationId, LargeObjectLOidPNIndexId, > + LargeObjectMetadataRelationId, LargeObjectMetadataOidIndexId); > [...] > appendPQExpBufferStr(loHorizonQry, "\n-- For binary upgrade, set pg_largeobject relfrozenxid and relminmxid\n"); > + appendPQExpBufferStr(lomHorizonQry, "\n-- For binary upgrade, set pg_largeobject_metadata relfrozenxid and relminmxid\n"); > appendPQExpBufferStr(loOutQry, "\n-- For binary upgrade, preserve pg_largeobject and index relfilenodes\n"); > + appendPQExpBufferStr(lomOutQry, "\n-- For binary upgrade, preserve pg_largeobject_metadata and index relfilenodes\n"); > > Is all that really required when upgrading from a cluster in the > 9.3~15 range? No, that stuff is discarded for upgrades from those versions. My intent was to maintain readability by avoiding lots of version checks. FWIW I originally put all of the pg_large_object_metadata stuff in a separate block, but that resulted in a lot of copy/pasted code. I'm happy to adjust it as you see fit. -- nathan
Commits
-
pg_upgrade: Use COPY for LO metadata for upgrades from < v12.
- b33f75361284 19 (unreleased) landed
-
pg_upgrade: Fix handling of pg_largeobject_metadata.
- 158408fef8b9 19 (unreleased) landed
-
pg_upgrade: Transfer pg_largeobject_metadata's files when possible.
- 3bcfcd815e1a 19 (unreleased) landed
-
Rearrange pg_dump's handling of large objects for better efficiency.
- a45c78e3284b 17.0 cited
-
Expand AclMode to 64 bits
- 7b378237aa80 16.0 cited
-
Fix pg_upgrade for oid removal.
- 12a53c732ced 12.0 cited