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 1smEAl-004BQS-Lf for pgsql-docs@arkaria.postgresql.org; Thu, 05 Sep 2024 15:13:23 +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 1smEAj-00CJlu-U9 for pgsql-docs@arkaria.postgresql.org; Thu, 05 Sep 2024 15:13:22 +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 1smEAj-00CJjd-M5 for pgsql-docs@lists.postgresql.org; Thu, 05 Sep 2024 15:13:22 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1smEAh-000IGe-Jz for pgsql-docs@lists.postgresql.org; Thu, 05 Sep 2024 15:13:20 +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 485FDIZh1847618; Thu, 5 Sep 2024 11:13:18 -0400 From: Tom Lane To: Alain Bourgeois cc: "pgsql-docs@lists.postgresql.org" Subject: Re: pg_upgrade -c cannot be run if old cluster is running In-reply-to: References: <172546462173.8361.7114078895863039790@wrigleys.postgresql.org> <1692842.1725482754@sss.pgh.pa.us> <1827652.1725543542@sss.pgh.pa.us> <1845283.1725548224@sss.pgh.pa.us> Comments: In-reply-to Alain Bourgeois message dated "Thu, 05 Sep 2024 15:04:34 -0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1847616.1725549198.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Thu, 05 Sep 2024 11:13:18 -0400 Message-ID: <1847617.1725549198@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Alain Bourgeois writes: > When the cluster was created, we did initdb /var/lib/pgsql10/data, the = storagebox was not available. > Then storagebox was delivered, we copied data folder to storagebox in /m= nt/pgdata/pgdir and changed postgresql.conf. We didn't delete existing dat= afiles from /var/lib/pgsql10/data (db was empty). Yeah, after further experimentation I saw that pg_upgrade would fail in a pretty obvious way unless the supposedly-config-only directory also contains a full set of subdirectories (base, pg_wal, etc). We could imagine removing that check for PG_VERSION. I don't think that the ensuing call of "postgres -C data_directory" would add anything meaningful to pg_upgrade's runtime. But then you'd see "Finding the real data directory" every time, indeed twice (for source and target directories). That seems like it would create more confusion than is justified. On the whole I think this is self-inflicted damage. Leaving that stuff around was just asking for confusion. regards, tom lane