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 1lJIoe-0004CH-Mw for pgsql-hackers@arkaria.postgresql.org; Mon, 08 Mar 2021 16:33:08 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lJIod-0001c2-B3 for pgsql-hackers@arkaria.postgresql.org; Mon, 08 Mar 2021 16:33:07 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lJIod-0001br-4I for pgsql-hackers@lists.postgresql.org; Mon, 08 Mar 2021 16:33:07 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lJIob-0007CP-5h for pgsql-hackers@postgresql.org; Mon, 08 Mar 2021 16:33:06 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 128GX2LI1742699; Mon, 8 Mar 2021 11:33:02 -0500 From: Tom Lane To: Robins Tharakan cc: Magnus Hagander , Peter Eisentraut , "pgsql-hackers@postgresql.org" Subject: Re: pg_upgrade failing for 200+ million Large Objects In-reply-to: References: Comments: In-reply-to Robins Tharakan message dated "Tue, 09 Mar 2021 01:13:02 +1100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1742697.1615221182.1@sss.pgh.pa.us> Date: Mon, 08 Mar 2021 11:33:02 -0500 Message-ID: <1742698.1615221182@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Robins Tharakan writes: > On Mon, 8 Mar 2021 at 23:34, Magnus Hagander wrote: >> Without looking, I would guess it's the schema reload using >> pg_dump/pg_restore and not actually pg_upgrade itself. This is a known >> issue in pg_dump/pg_restore. And if that is the case -- perhaps just >> running all of those in a single transaction would be a better choice? >> One could argue it's still not a proper fix, because we'd still have a >> huge memory usage etc, but it would then only burn 1 xid instead of >> 500M... > (I hope I am not missing something but) When I tried to force pg_restore to > use a single transaction (by hacking pg_upgrade's pg_restore call to use > --single-transaction), it too failed owing to being unable to lock so many > objects in a single transaction. It does seem that --single-transaction is a better idea than fiddling with the transaction wraparound parameters, since the latter is just going to put off the onset of trouble. However, we'd have to do something about the lock consumption. Would it be sane to have the backend not bother to take any locks in binary-upgrade mode? regards, tom lane