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.94.2) (envelope-from ) id 1syhTl-001dON-RK for pgsql-bugs@arkaria.postgresql.org; Thu, 10 Oct 2024 00:56:35 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1syhTk-008JRr-Iw for pgsql-bugs@arkaria.postgresql.org; Thu, 10 Oct 2024 00:56:32 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1syhTi-008JRj-St for pgsql-bugs@lists.postgresql.org; Thu, 10 Oct 2024 00:56:32 +0000 Received: from fout-b7-smtp.messagingengine.com ([202.12.124.150]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1syhTc-0007f0-BV for pgsql-bugs@lists.postgresql.org; Thu, 10 Oct 2024 00:56:29 +0000 Received: from phl-compute-01.internal (phl-compute-01.phl.internal [10.202.2.41]) by mailfout.stl.internal (Postfix) with ESMTP id D8D3C1140080; Wed, 9 Oct 2024 20:56:22 -0400 (EDT) Received: from phl-imap-09 ([10.202.2.99]) by phl-compute-01.internal (MEProxy); Wed, 09 Oct 2024 20:56:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eulerto.com; h= cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1728521782; x=1728608182; bh=B9nCr0y8LY /eRaPy6vuEGHMWWDx/9DM//WXycvOSVk8=; b=d3EDylk2WCJCHxJqiZyvEKpJdE stbVUJGBCnexMwxwT6w2LZKsSNQpV27F8VfOKd+GtYx2Nf84q1RxSUMeQsI1BqJU qJE3yQPDIJoTX+P4pa9DNfVwjWN08vGkXnSJKl/p9z/TRW7enZlWfiNUJhrl4XMF b7AUhyIkFocO3M1A3rQJ+4Ve5S5+dNJtC99c59gXmzuYEh/mmF2ygr07tfs3yBjW NYJ59p0aR8QQa07D5v4veAnos5Aa9GuGw55fa3Jo8EhM8DikP0MLRJBRpKQANlQD b8TcjS+T48jTaW8YZhq2gFBdU9WWORmIortmB4INBPhg10WkXpZnEwKtexMA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1728521782; x=1728608182; bh=B9nCr0y8LY/eRaPy6vuEGHMWWDx/ 9DM//WXycvOSVk8=; b=Fs5ybO5NKWMmw0Jgn3PQP++vHnktRvgNDaratYxHCbIL cqDzRCtwV9aCdmpVukDX4re91Ng97SAuUOqP0nkCgasCMe6usHRPQbsiWo1Ediuu eWQIeLuO79c6ok9W6avDLpZkErydMHuIAOKdHOQWVVvrLSZ/rclsuWqZLePyULUT njXHsVLDerSa8DF0j25hOIvIL30w8J7EHl/P+/73bnX1+5D2mZqSoHR07msEBl9W MwFKdx8yB2gSrFgp2tBTLE6YkVafw8UllL4EgbseVP6cOVxENzeeVDof7+XGQdGR vZ4181MHtjp+cCN5t9GzWgjIs/hO6t31Sue3bF/jHw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvdefgedggeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhepofggfffhvffkjghfufgtsegrtderreertdejnecu hfhrohhmpedfgfhulhgvrhcuvfgrvhgvihhrrgdfuceovghulhgvrhesvghulhgvrhhtoh drtghomheqnecuggftrfgrthhtvghrnhepffdthfeukedvtdeiteekhefhhffhueelfeet udfggeduheeiveffffekveejtedvnecuffhomhgrihhnpehpohhsthhgrhgvshhqlhdroh hrghdpvghnthgvrhhprhhishgvuggsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomhepvghulhgvrhesvghulhgvrhhtohdrtghomhdpnh gspghrtghpthhtohepfedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepsghinhhg rdiguhdruhhhsehfuhhjihhfihhlmhdrtghomhdprhgtphhtthhopegurghvihgurdhgrd hjohhhnhhsthhonhesghhmrghilhdrtghomhdprhgtphhtthhopehpghhsqhhlqdgsuhhg sheslhhishhtshdrphhoshhtghhrvghsqhhlrdhorhhg X-ME-Proxy: Feedback-ID: i0c21471d:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 30A6A780068; Wed, 9 Oct 2024 20:56:21 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface MIME-Version: 1.0 Date: Wed, 09 Oct 2024 21:56:00 -0300 From: "Euler Taveira" To: "Bing Xu" , "David G. Johnston" , "pgsql-bugs@lists.postgresql.org" Message-Id: In-Reply-To: References: <18635-7a3e4e903d99c814@postgresql.org> Subject: Re: BUG #18635: " $libdir/adminpack could not be loaded" error with pg_upgrade to PostgreSQL17 Content-Type: multipart/alternative; boundary=7571bcc9dc4745279becc6ec71fbcc95 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --7571bcc9dc4745279becc6ec71fbcc95 Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, Oct 9, 2024, at 6:17 AM, Bing Xu wrote: > I uninstalled adminpack from the database and was able to upgrade to PostgreSQL 17 normally, > but why is there no record in the PostgreSQL 17 upgrade manual? > ... because this list can be large along the years. That's why pg_upgrade adopts loadable_libraries.txt file that reports the loadable module failures. You should run pg_upgrade with --check option and if there is an error, check the referred file. 8<----------------------------------------------------------------------------8< $ /h/pg17/bin/pg_upgrade -b /h/pg16/bin -B /h/pg17/bin -d /tmp/foo16 -D /tmp/foo17 --check Performing Consistency Checks ----------------------------- Checking cluster versions ok Checking database user is the install user ok Checking database connection settings ok Checking for prepared transactions ok Checking for contrib/isn with bigint-passing mismatch ok Checking data type usage ok Checking for presence of required libraries fatal Your installation references loadable libraries that are missing from the new installation. You can add these libraries to the new installation, or remove the functions using them from the old installation. A list of problem libraries is in the file: /tmp/foo17/pg_upgrade_output.d/20241009T213155.590/loadable_libraries.txt Failure, exiting $ cat /tmp/foo17/pg_upgrade_output.d/20241009T213948.961/loadable_libraries.txt could not load library "$libdir/adminpack": ERROR: could not access file "$libdir/adminpack": No such file or directory In database: postgres 8<----------------------------------------------------------------------------8< It is highly recommended to read all release notes [1] from version X+1 to Y where X is your current version and Y is your new version before upgrading. In this particular case (adminpack), even though it belongs to Additional Modules section, I would add it to Migration to Version 17 because it is an incompatibility with the previous releases. Well, this ship has already sailed and it is documented (lines below). [1] https://www.postgresql.org/docs/17/release-17.html#RELEASE-17-MODULES -- Euler Taveira EDB https://www.enterprisedb.com/ --7571bcc9dc4745279becc6ec71fbcc95 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Wed, Oct 9, 2024, at 6:17 AM, Bing X= u wrote:

I uninstalled adminpack fr= om the database and was able to upgrade to PostgreSQL 17 normally,

but why is there no record in the PostgreSQL 17 upgrade man= ual?



... because this list can be large along the = years. That's why pg_upgrade adopts
loadable_libraries.txt= file that reports the loadable module failures. You
shoul= d run pg_upgrade with --check option and if there is an error, check the=
referred file.

8<--------= --------------------------------------------------------------------8<= ;
$ /h/pg17/bin/pg_upgrade -b /h/pg16/bin -B /h/pg17/bin -= d /tmp/foo16 -D /tmp/foo17 --check
Performing Consistency = Checks
-----------------------------
Checkin= g cluster versions         =             =             =     ok
Checking database user is the instal= l user           =          ok
Checki= ng database connection settings       = ;            = ;      ok
Checking for prepared t= ransactions          &= nbsp;           &= nbsp;     ok
Checking for contrib/isn = with bigint-passing mismatch       &n= bsp; ok
Checking data type usage    &n= bsp;           &n= bsp;           &n= bsp;         ok
Ch= ecking for presence of required libraries     &= nbsp;           &= nbsp; fatal

Your installation references lo= adable libraries that are missing from the
new installatio= n.  You can add these libraries to the new installation,
<= div>or remove the functions using them from the old installation.  = A list of
problem libraries is in the file:
=     /tmp/foo17/pg_upgrade_output.d/20241009T213155.590/lo= adable_libraries.txt
Failure, exiting

$ cat /tmp/foo17/pg_upgrade_output.d/20241009T213948.961/loadab= le_libraries.txt
could not load library "$libdir/adminpack= ": ERROR:  could not access file "$libdir/adminpack": No such file = or directory
In database: postgres

8<-------------------------------------------------------------= ---------------8<

It is highly recommend= ed to read all release notes [1] from version X+1 to Y
whe= re X is your current version and Y is your new version before upgrading.=

In this particular case (adminpack), even = though it belongs to Additional
Modules section, I would a= dd it to Migration to Version 17 because it is an
incompat= ibility with the previous releases. Well, this ship has already sailed
and it is documented (lines below).




--
Euler Taveira
EDB&n= bsp;  https://www.enterpr= isedb.com/

--7571bcc9dc4745279becc6ec71fbcc95--