Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lNejV-0002BM-LY for pgsql-hackers@arkaria.postgresql.org; Sat, 20 Mar 2021 16:45:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lNejT-0002e9-UC for pgsql-hackers@arkaria.postgresql.org; Sat, 20 Mar 2021 16:45:47 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lNejT-0002e2-NE for pgsql-hackers@lists.postgresql.org; Sat, 20 Mar 2021 16:45:47 +0000 Received: from momjian.us ([72.94.173.45]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lNejM-0000tE-MI for pgsql-hackers@postgresql.org; Sat, 20 Mar 2021 16:45:47 +0000 Received: from bruce by momjian.us with local (Exim 4.92) (envelope-from ) id 1lNejI-0006cH-7K; Sat, 20 Mar 2021 12:45:36 -0400 Date: Sat, 20 Mar 2021 12:45:36 -0400 From: Bruce Momjian To: Tom Lane Cc: Jan Wieck , Magnus Hagander , Robins Tharakan , Peter Eisentraut , "pgsql-hackers@postgresql.org" Subject: Re: pg_upgrade failing for 200+ million Large Objects Message-ID: <20210320164536.GB7968@momjian.us> References: <1742698.1615221182@sss.pgh.pa.us> <1743618.1615222719@sss.pgh.pa.us> <4fbf92f2-ec91-f4fa-a259-f0968e34f3d7@wi3ck.info> <181907.1616253799@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <181907.1616253799@sss.pgh.pa.us> User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sat, Mar 20, 2021 at 11:23:19AM -0400, Tom Lane wrote: > I wonder if pg_dump could improve matters cheaply by aggregating the > large objects by owner and ACL contents. That is, do > > select distinct lomowner, lomacl from pg_largeobject_metadata; > > and make just *one* BLOB TOC entry for each result. Then dump out > all the matching blobs under that heading. > > A possible objection is that it'd reduce the ability to restore blobs > selectively, so maybe we'd need to make it optional. > > Of course, that just reduces the memory consumption on the client > side; it does nothing for the locks. Can we get away with releasing the > lock immediately after doing an ALTER OWNER or GRANT/REVOKE on a blob? Well, in pg_upgrade mode you can, since there are no other cluster users, but you might be asking for general pg_dump usage. -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion.