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-05T01:23:58Z
Lists: pgsql-hackers
Attachments
On Thu, Sep 04, 2025 at 01:59:36PM +0900, Michael Paquier wrote: > On Tue, Sep 02, 2025 at 09:43:40AM -0500, Nathan Bossart wrote: >> 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. > > I would argue in favor of these additions. Security labels are not > the most popular thing ever, AFAIK, but your patch makes the need more > relevant to have. The cheapest approach would be to add a LO creation > pattern in src/bin/pg_dump/t/002_pg_dump.pl, with an EXTRA_INSTALL > pointing at src/test/modules/dummy_seclabel/ to be able to create the > security label (we already do that in pg_upgrade and pg_basebackup so > the trick works). That should be enough to make sure that the binary > upgrade dumps have the seclabel data included. It's a bit funky, I > agree. So if you think that this is not worth the test cycles, I > won't push hard on this point, either. Ah, I'd forgotten about EXTRA_INSTALL. That simplifies things. There's enough special handling for large objects in pg_upgrade that I think we ought to test it end-to-end, so I sneaked it into 006_tranfer_modes.pl. WDYT? -- 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