pg_upgrade: Transfer pg_largeobject_metadata's files when possible.
authorNathan Bossart <nathan@postgresql.org>
Mon, 8 Sep 2025 19:19:48 +0000 (14:19 -0500)
committerNathan Bossart <nathan@postgresql.org>
Mon, 8 Sep 2025 19:19:48 +0000 (14:19 -0500)
commit3bcfcd815e1a2d51772ba27e0d034467f0344f15
tree182a4682abf98971b70f895ef4a9134a59365d03
parent4b5f206de2bb9152a99a5c218caf2580cc5a0e9e
pg_upgrade: Transfer pg_largeobject_metadata's files when possible.

Commit 161a3e8b68 taught pg_upgrade to use COPY for large object
metadata for upgrades from v12 and newer, which is much faster to
restore than the proper large object commands.  For upgrades from
v16 and newer, we can take this a step further and transfer the
large object metadata files as if they were user tables.  We can't
transfer the files from older versions because the aclitem data
type (needed by pg_largeobject_metadata.lomacl) changed its storage
format in v16 (see commit 7b378237aa).  Note that this commit is
essentially a revert of commit 12a53c732c.

There are a couple of caveats.  First, we still need to COPY the
corresponding pg_shdepend rows for large objects.  Second, we need
to COPY anything in pg_largeobject_metadata with a comment or
security label, else restoring those will fail.  This means that an
upgrade in which every large object has a comment or security label
won't gain anything from this commit, but it should at least avoid
making those unusual use-cases any worse.

pg_upgrade must also take care to transfer the relfilenodes of
pg_largeobject_metadata and its index, as was done for
pg_largeobject in commits d498e052b4 and bbe08b8869.

Reviewed-by: Michael Paquier <michael@paquier.xyz>
Discussion: https://postgr.es/m/aJ3_Gih_XW1_O2HF%40nathan
src/backend/commands/tablecmds.c
src/bin/pg_dump/pg_dump.c
src/bin/pg_upgrade/Makefile
src/bin/pg_upgrade/info.c
src/bin/pg_upgrade/pg_upgrade.c
src/bin/pg_upgrade/t/006_transfer_modes.pl