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 1lJD4j-0004mT-Sr for pgsql-hackers@arkaria.postgresql.org; Mon, 08 Mar 2021 10:25:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lJD4i-0004kE-S5 for pgsql-hackers@arkaria.postgresql.org; Mon, 08 Mar 2021 10:25:20 +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 1lJD4i-0004k7-LU for pgsql-hackers@lists.postgresql.org; Mon, 08 Mar 2021 10:25:20 +0000 Received: from forward2-smtp.messagingengine.com ([66.111.4.226]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lJD4f-0006Mm-FE for pgsql-hackers@postgresql.org; Mon, 08 Mar 2021 10:25:20 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailforward.nyi.internal (Postfix) with ESMTP id CA5D01940C4B; Mon, 8 Mar 2021 05:25:15 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Mon, 08 Mar 2021 05:25:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=VjakfD/gqrRIHrC2bxJ0FFCNQTEx+TmG3U0Ce4xpq MQ=; b=PIzq3tyNYk2uayEOicdAQjYQ1ZRQDPWB6aUWepFX3rIj/qniFK/Bi48ez G5umC6zg8fiqMnOFtOrWnHxtuMfzUN/lnYtVgsAny4yq+mes7lFUJ2D2ANiBpxLX STkJedgaO2Pqn1pm98/acZibFaxnILqbrNWBvZ4K2mbEt41ddFE/Z9S8jkcGSy5p 777UAOKDTd9qDtsqOaX2MDX5ykNI0ypUHgyykj7WGI1e7xQkOXsXS3FZhwVYSKv4 4SoVfMAMjw75N96EdVEUg/3YxNHmZ/dpXRhs76boo71GRClj6GgK9DnT5OtEq5SV 2BHS+uCoDsjx36qYpp01ynhnjCqzQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudduvddgudefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhkffffgggjggtgfesthejredttdefheenucfhrhhomheprfgvthgv rhcugfhishgvnhhtrhgruhhtuceophgvthgvrhdrvghishgvnhhtrhgruhhtsegvnhhtvg hrphhrihhsvggusgdrtghomheqnecuggftrfgrthhtvghrnhephfefleefueevuddvffeh jedtjeejgfelhfdtvdffheeludetudegfeeftdffffejnecukfhppeekjedrudejjedrie elrddugedtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho mhepphgvthgvrhdrvghishgvnhhtrhgruhhtsegvnhhtvghrphhrihhsvggusgdrtghomh X-ME-Proxy: Received: from laptop206oxuk.local (p57b1458c.dip0.t-ipconnect.de [87.177.69.140]) by mail.messagingengine.com (Postfix) with ESMTPA id 978481080057; Mon, 8 Mar 2021 05:25:14 -0500 (EST) Subject: Re: pg_upgrade failing for 200+ million Large Objects To: "Tharakan, Robins" , "pgsql-hackers@postgresql.org" References: <2543eda3e609455e9cf283646a8b2bc8@EX13D05UWC001.ant.amazon.com> From: Peter Eisentraut Message-ID: Date: Mon, 8 Mar 2021 11:25:13 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: <2543eda3e609455e9cf283646a8b2bc8@EX13D05UWC001.ant.amazon.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 07.03.21 09:43, Tharakan, Robins wrote: > Attached is a proof-of-concept patch that allows Postgres to perform > pg_upgrade if the instance has Millions of objects. > > It would be great if someone could take a look and see if this patch is in > the right direction. There are some pending tasks (such as documentation / > pg_resetxlog vs pg_resetwal related changes) but for now, the patch helps > remove a stalemate where if a Postgres instance has a large number > (accurately speaking 146+ Million) of Large Objects, pg_upgrade fails. This > is easily reproducible and besides deleting Large Objects before upgrade, > there is no other (apparent) way for pg_upgrade to complete. > > The patch (attached): > - Applies cleanly on REL9_6_STABLE - > c7a4fc3dd001646d5938687ad59ab84545d5d043 > - 'make check' passes > - Allows the user to provide a constant via pg_upgrade command-line, that > overrides the 2 billion constant in pg_resetxlog [1] thereby increasing the > (window of) Transaction IDs available for pg_upgrade to complete. Could you explain what your analysis of the problem is and why this patch (might) fix it? Right now, all I see here is, pass a big number via a command-line option and hope it works.