summaryrefslogtreecommitdiff
path: root/src/backend/tcop/postgres.c
diff options
context:
space:
mode:
authorNathan Bossart <nathan@postgresql.org>2025-09-08 14:19:48 -0500
committerNathan Bossart <nathan@postgresql.org>2025-09-08 14:19:48 -0500
commit3bcfcd815e1a2d51772ba27e0d034467f0344f15 (patch)
tree182a4682abf98971b70f895ef4a9134a59365d03 /src/backend/tcop/postgres.c
parent4b5f206de2bb9152a99a5c218caf2580cc5a0e9e (diff)
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
Diffstat (limited to 'src/backend/tcop/postgres.c')
0 files changed, 0 insertions, 0 deletions