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 1sxtYA-00D4O2-0V for pgsql-hackers@arkaria.postgresql.org; Mon, 07 Oct 2024 19:37:46 +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 1sxtY8-00FDib-1s for pgsql-hackers@arkaria.postgresql.org; Mon, 07 Oct 2024 19:37:44 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sxtY7-00FDiS-Ot for pgsql-hackers@lists.postgresql.org; Mon, 07 Oct 2024 19:37:43 +0000 Received: from momjian.us ([72.94.173.45]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sxtY3-0034dp-Ck for pgsql-hackers@postgresql.org; Mon, 07 Oct 2024 19:37:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=momjian.us; s=2024011501; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description; bh=PezdZkmXnmhOfTDa7Ffw8X7iOJx8aoU4hHb8mF6Q9iE=; b=PfEQF AWcSnAGNVufXTfzMYTGIuN2qn4g3GtSVGogpEb7ZokH/cpXJ79KCV+B0VrFFfPgs4x72vo2Ej4Jf1 YAJylsa0w8vuTruZubx6QUCi/pwdm/VK2LD6GoVDTAmWengvWmnTor4OzX+BjL4w35cioNTs/hgsa Vd9oTTsQ/zRavzflFwDu3gT8uajjbdSdtbuMeD7nAt5Wc361QtiTNKvbjUkWGSYDLajtSFTS+msbr dt6h/uJgX0WbfzkAzAVAwtU2CVlOsc9T4CVcLasdDN/U6cPJPJk32oqtK0MhUyAhJK97nz80BiasQ 8748qLSWiXmcqmrlCT/zstHurmBfg==; Received: from bruce by momjian.us with local (Exim 4.96) (envelope-from ) id 1sxtXz-00716v-1S; Mon, 07 Oct 2024 15:37:35 -0400 Date: Mon, 7 Oct 2024 15:37:35 -0400 From: Bruce Momjian To: Daniel Gustafsson Cc: Tom Lane , Nathan Bossart , Thomas Krennwallner , PostgreSQL Hackers Subject: Re: pg_upgrade check for invalid databases Message-ID: References: <1455756.1727708139@sss.pgh.pa.us> <1638096.1727734841@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Oct 1, 2024 at 09:28:54AM +0200, Daniel Gustafsson wrote: > > On 1 Oct 2024, at 00:20, Tom Lane wrote: > > > > Daniel Gustafsson writes: > >>> On 30 Sep 2024, at 16:55, Tom Lane wrote: > >>> TBH I'm not finding anything very much wrong with the current > >>> behavior... this has to be a rare situation, do we need to add > >>> debatable behavior to make it easier? > > > >> One argument would be to make the checks consistent, pg_upgrade generally tries > >> to report all the offending entries to help the user when fixing the source > >> database. Not sure if it's a strong enough argument for carrying code which > >> really shouldn't see much use though. > > > > OK, but the consistency argument would be to just report and fail. > > I don't think there's a precedent in other pg_upgrade checks for > > trying to fix problems automatically. > > Correct, sorry for being unclear. The consistency argument would be to expand > pg_upgrade to report all invalid databases rather than just the first found; > attempting to fix problems would be a new behavior. Yes, historically pg_upgrade will fail if it finds anything unusual, mostly because what it does normally is already scary enough. If users what pg_upgrade to do cleanups, it would be enabled by a separate flag, or even a new command-line app. -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com When a patient asks the doctor, "Am I going to die?", he means "Am I going to die soon?"