Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vo3H1-00F2dK-0v for pgsql-hackers@arkaria.postgresql.org; Thu, 05 Feb 2026 17:36:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vo3H0-000N5t-1H for pgsql-hackers@arkaria.postgresql.org; Thu, 05 Feb 2026 17:36:10 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vo3H0-000N5j-0G for pgsql-hackers@lists.postgresql.org; Thu, 05 Feb 2026 17:36:09 +0000 Received: from mail-oa1-x30.google.com ([2001:4860:4864:20::30]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1vo3Gu-00000001Dyk-33gA for pgsql-hackers@lists.postgresql.org; Thu, 05 Feb 2026 17:36:09 +0000 Received: by mail-oa1-x30.google.com with SMTP id 586e51a60fabf-409521ba360so820426fac.2 for ; Thu, 05 Feb 2026 09:36:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770312963; x=1770917763; darn=lists.postgresql.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=63v0RQw5Nn2L3ilxzjFjo+UsdHHoW72a6TaASeKZzz8=; b=IituzAtRLeKYddFKSwtxaV50OgOO9DWKsIRehu+JrfvmtBJ0W23u3hwb4oefHsSvfX jx/DOdUGepiwKAKaMIyPqUYQFrAMgewtNeyYH4yxjIP3zUmij59fycJBLXk0s7EWgL2h T9NbjRIIzIaqRAFfdWOWeP1By7u6JstnEB2inRwHYV9p5AS7oaySxglF9I0B7A9lOhpp YL6TFXw8/BeTfQTyV+FH5UzEhV1ssnZp3yhnjMwExY/F8xPxr19v770xzQzbVVqC4rzu 8FhC61rOSqw6OTBf+H2wvTRr6+VDRoVQKvvA0fWtPSCqumekUqBHLtPjfV8/2k4syjdk L+Fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770312963; x=1770917763; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=63v0RQw5Nn2L3ilxzjFjo+UsdHHoW72a6TaASeKZzz8=; b=QfEFfyXxDofpD7R8hhCzWS+yxUqFHfMs0wwdyXPJurxLfV1hz8jALiCP0STw5MA0M/ mtRjo0M3EiNxJRasxVuHm+C/SoygKmBDi7kdAPM8qNbK8prlS0rJD3OPfN7vGEUACKWn H5KouYy51Kr4Ec8xAfNwRXhtEH0NRBPhrUKLnH0ZM8iBKO210OcJvB8iVBAPY1NLD7Y6 rvSerd+9LR1pfbHRdT4y1a13TLXR5uVGFK4aOaBQrKwb+JIYinVI24Qx5iINJzCah5Ga EBB09aXSmQl8P4QlnKNP2gDap37ugrExueXgHWq8miVpU+5FSVe92c90yiDBaMJUaI/3 J9dw== X-Forwarded-Encrypted: i=1; AJvYcCWqsXpcl6lteDwzP/BuQD4PQsOIpQUM1q/19ogRGW+dsbjsJc2tuJQcUL5SJaXldHOHgZDjoSsxLJLCJdFV@lists.postgresql.org X-Gm-Message-State: AOJu0YzvJpAdoOFexN8LKU/FrKzNar7qxYgMXZGNqcNch0nsVVoioEJD TECb7jCS9efisoBaXsp6h2qi8d4tF/Zfws5RYpvZj9hIrqsIxgWrSU7R X-Gm-Gg: AZuq6aKJINezaadajHSc4Gn5YGBdGDX0GGn+ug+g5gtOe/zVPQ7E9TAOxYxvlQoFEbY csGaByRNZjHbeXQotqc8MhS76DI6uBEzjI9EX8SigVMx4S+hrYC73PgnilUQwVZCSnltJcUKyje 3m6oy0x68HcuWE9YSn9uoWfdg9Hf7p23mVsvFDIEN0zde3Nf4TZctF5g2ZJ/IqJDcTp+wATUaTx Qht/n05pmKOD7vSXuUSgDqKaOrABVi91KO1pJBj2wa98iCeT0ki244gq0egpsyJSdnvh5D/qfuD +/IkF3CYH4upeuQkgcheShNgPUqL90vOtLoFeEGAMh6dWXDi546bYHf361WgH5P2kpEO7ABJ72T VCLbVAoRz/KwD+lDkZfBjeEQPLKizpZI5iYemaGbPYIE/9lUOCiWDL0IFIs0VfNGKHWmt46Es8J 7ty8soAUzkT16cN2jXtHl8n2+MUPbaMQ5h4jtaSUrLn3Dziek1rAvq+++6xapEECGVPSxX+F0w0 FJb X-Received: by 2002:a05:6870:a113:b0:40a:65ee:d307 with SMTP id 586e51a60fabf-40a96ce54fbmr31704fac.26.1770312962617; Thu, 05 Feb 2026 09:36:02 -0800 (PST) Received: from nathan (162-195-168-172.lightspeed.stlsmo.sbcglobal.net. [162.195.168.172]) by smtp.gmail.com with ESMTPSA id 586e51a60fabf-40a630bc6easm3338015fac.4.2026.02.05.09.36.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Feb 2026 09:36:02 -0800 (PST) Date: Thu, 5 Feb 2026 11:36:00 -0600 From: Nathan Bossart To: Andres Freund Cc: Michael Paquier , Tom Lane , Nitin Motiani , Hannu Krosing , PostgreSQL Hackers Subject: Re: pg_upgrade: transfer pg_largeobject_metadata's files when possible Message-ID: References: <3yd2ss6n7xywo6pmhd7jjh3bqwgvx35bflzgv3ag4cnzfkik7m@hiyadppqxx6w> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="07s5YKCMhGM2F9Zp" Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --07s5YKCMhGM2F9Zp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Feb 05, 2026 at 11:19:46AM -0500, Andres Freund wrote: > It certainly seems better than what we do now. Still feels pretty grotty and > error prone to me that we fill the catalog table and then throw the contents > out. Before I go any further with this approach, I thought of something else we could do that I believe is worth considering... As of commit 3bcfcd815e, the only reason we are dumping any of pg_largeobject_metadata at all is to avoid an ERROR during COMMENT ON or SECURITY LABEL ON because the call to LargeObjectExists() in get_object_address() returns false. If we bypass that check in binary-upgrade mode, we can skip dumping pg_largeobject_metadata entirely. The attached patch passes our existing tests, and it seems to create the expected binary-upgrade-mode dump files, too. I haven't updated any of the comments yet. -- nathan --07s5YKCMhGM2F9Zp Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0001-fix-pg_largeobject_metadata-file-transfer.patch From 1fa1890f6bf98b718118f070226d8b102073e165 Mon Sep 17 00:00:00 2001 From: Nathan Bossart Date: Thu, 5 Feb 2026 11:26:39 -0600 Subject: [PATCH v2 1/1] fix pg_largeobject_metadata file transfer --- src/backend/catalog/objectaddress.c | 2 +- src/bin/pg_dump/pg_dump.c | 53 +++++++++++++---------------- 2 files changed, 24 insertions(+), 31 deletions(-) diff --git a/src/backend/catalog/objectaddress.c b/src/backend/catalog/objectaddress.c index 02af64b82c6..1762146c09a 100644 --- a/src/backend/catalog/objectaddress.c +++ b/src/backend/catalog/objectaddress.c @@ -1046,7 +1046,7 @@ get_object_address(ObjectType objtype, Node *object, address.classId = LargeObjectRelationId; address.objectId = oidparse(object); address.objectSubId = 0; - if (!LargeObjectExists(address.objectId)) + if (!LargeObjectExists(address.objectId) && !IsBinaryUpgrade) { if (!missing_ok) ereport(ERROR, diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c index 2bebefd0ba2..6bcb2f61fe8 100644 --- a/src/bin/pg_dump/pg_dump.c +++ b/src/bin/pg_dump/pg_dump.c @@ -1129,19 +1129,11 @@ main(int argc, char **argv) */ if (dopt.binary_upgrade && fout->remoteVersion >= 120000) { - TableInfo *lo_metadata = findTableByOid(LargeObjectMetadataRelationId); - TableInfo *shdepend = findTableByOid(SharedDependRelationId); + TableInfo *shdepend; - makeTableDataInfo(&dopt, lo_metadata); + shdepend = findTableByOid(SharedDependRelationId); makeTableDataInfo(&dopt, shdepend); - /* - * Save pg_largeobject_metadata's dump ID for use as a dependency for - * pg_shdepend and any large object comments/seclabels. - */ - lo_metadata_dumpId = lo_metadata->dataObj->dobj.dumpId; - addObjectDependency(&shdepend->dataObj->dobj, lo_metadata_dumpId); - /* * Only dump large object shdepend rows for this database. */ @@ -1149,22 +1141,20 @@ main(int argc, char **argv) "AND dbid = (SELECT oid FROM pg_database " " WHERE datname = current_database())"; - /* - * If upgrading from v16 or newer, only dump large objects with - * comments/seclabels. For these upgrades, pg_upgrade can copy/link - * pg_largeobject_metadata's files (which is usually faster) but we - * still need to dump LOs with comments/seclabels here so that the - * subsequent COMMENT and SECURITY LABEL commands work. pg_upgrade - * can't copy/link the files from older versions because aclitem - * (needed by pg_largeobject_metadata.lomacl) changed its storage - * format in v16. - */ - if (fout->remoteVersion >= 160000) - lo_metadata->dataObj->filtercond = "WHERE oid IN " - "(SELECT objoid FROM pg_description " - "WHERE classoid = " CppAsString2(LargeObjectRelationId) " " - "UNION SELECT objoid FROM pg_seclabel " - "WHERE classoid = " CppAsString2(LargeObjectRelationId) ")"; + if (fout->remoteVersion < 160000) + { + TableInfo *lo_metadata; + + lo_metadata = findTableByOid(LargeObjectMetadataRelationId); + makeTableDataInfo(&dopt, lo_metadata); + + /* + * Save pg_largeobject_metadata's dump ID for use as a dependency + * for pg_shdepend and any large object comments/seclabels. + */ + lo_metadata_dumpId = lo_metadata->dataObj->dobj.dumpId; + addObjectDependency(&shdepend->dataObj->dobj, lo_metadata_dumpId); + } } /* @@ -4079,7 +4069,7 @@ getLOs(Archive *fout) * We should've saved pg_largeobject_metadata's dump ID before * this point. */ - Assert(lo_metadata_dumpId); + Assert(lo_metadata_dumpId || fout->remoteVersion >= 160000); loinfo->dobj.dump &= ~(DUMP_COMPONENT_DATA | DUMP_COMPONENT_ACL | DUMP_COMPONENT_DEFINITION); @@ -4088,9 +4078,12 @@ getLOs(Archive *fout) * pg_largeobject_metadata so that any large object * comments/seclables are dumped after it. */ - loinfo->dobj.dependencies = (DumpId *) pg_malloc(sizeof(DumpId)); - loinfo->dobj.dependencies[0] = lo_metadata_dumpId; - loinfo->dobj.nDeps = loinfo->dobj.allocDeps = 1; + if (fout->remoteVersion < 160000) + { + loinfo->dobj.dependencies = (DumpId *) pg_malloc(sizeof(DumpId)); + loinfo->dobj.dependencies[0] = lo_metadata_dumpId; + loinfo->dobj.nDeps = loinfo->dobj.allocDeps = 1; + } } else loinfo->dobj.dump &= ~DUMP_COMPONENT_DATA; -- 2.50.1 (Apple Git-155) --07s5YKCMhGM2F9Zp--