Horton

Re: pg_upgrade: transfer pg_largeobject_metadata's files when possible

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Nathan Bossart <nathandbossart@gmail.com>
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-06T01:12:11Z
Lists: pgsql-hackers 
On Fri, Sep 05, 2025 at 01:12:49PM -0500, Nathan Bossart wrote:
> How does this look?

+    # We can only test security labels if both the old and new installations
+    # have dummy_seclabel.
+    my $test_seclabel = 1;
+    $old->start;
+    if (!$old->check_extension('dummy_seclabel'))
+    {
+        $test_seclabel = 0;
+    }
+    $old->stop;
+    $new->start;
+    if (!$new->check_extension('dummy_seclabel'))
+    {
+        $test_seclabel = 0;
+    }
+    $new->stop;

Yep.  This plan is safe to rely on.

A tiny comment I may have is that the LO numbers are hardcoded and
duplicated.  I would have used a variable to store these numbers.
Please feel free to ignore my picky-ism.
--
Michael

Commits

  1. pg_upgrade: Use COPY for LO metadata for upgrades from < v12.

  2. pg_upgrade: Fix handling of pg_largeobject_metadata.

  3. pg_upgrade: Transfer pg_largeobject_metadata's files when possible.

  4. Rearrange pg_dump's handling of large objects for better efficiency.

  5. Expand AclMode to 64 bits

  6. Fix pg_upgrade for oid removal.