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 1m9D9n-00050O-Ey for pgsql-hackers@arkaria.postgresql.org; Thu, 29 Jul 2021 21:01:31 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1m9D9m-0007DU-EE for pgsql-hackers@arkaria.postgresql.org; Thu, 29 Jul 2021 21:01:30 +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 1m9D9m-0007DM-7L for pgsql-hackers@lists.postgresql.org; Thu, 29 Jul 2021 21:01:30 +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 1m9D9k-0004mR-32 for pgsql-hackers@lists.postgresql.org; Thu, 29 Jul 2021 21:01:29 +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 16TL1OvW915982; Thu, 29 Jul 2021 17:01:24 -0400 From: Tom Lane To: Dave Cramer cc: Bruce Momjian , Alvaro Herrera , "David G. Johnston" , PostgreSQL Hackers Subject: Re: pg_upgrade does not upgrade pg_stat_statements properly In-reply-to: References: <20210729163448.GP9600@momjian.us> <202107291743.pqlj3s2uilfu@alvherre.pgsql> <20210729190645.GS9600@momjian.us> Comments: In-reply-to Dave Cramer message dated "Thu, 29 Jul 2021 15:27:49 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <915980.1627592484.1@sss.pgh.pa.us> Date: Thu, 29 Jul 2021 17:01:24 -0400 Message-ID: <915981.1627592484@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Dave Cramer writes: > So back to the original motivation for bringing this up. Recall that a > cluster was upgraded. Everything appeared to work fine, except that the > definitions of the functions were slightly different enough to cause a > fatal issue on restoring a dump from pg_dump. > Since pg_upgrade is now part of the core project, we need to make sure this > is not possible or be much more insistent that the user needs to upgrade > any extensions that require it. TBH, this seems like mostly the fault of the extension author. The established design is that the SQL-level objects will be carried forward verbatim by pg_upgrade. Therefore, any newer-version shared library MUST be able to cope sanely with SQL objects from some previous revision. The contrib modules provide multiple examples of ways to do this. If particular extension authors don't care to go to that much trouble, it's on their heads to document that their extensions are unsafe to pg_upgrade. regards, tom lane