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 1m9Hrk-0007GF-Et for pgsql-hackers@arkaria.postgresql.org; Fri, 30 Jul 2021 02:03:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1m9Hrh-0000OO-Fl for pgsql-hackers@arkaria.postgresql.org; Fri, 30 Jul 2021 02:03:09 +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 1m9Hrh-0000OG-5t for pgsql-hackers@lists.postgresql.org; Fri, 30 Jul 2021 02:03:09 +0000 Received: from mail-pl1-x62f.google.com ([2607:f8b0:4864:20::62f]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1m9Hrf-0001qV-1Z for pgsql-hackers@lists.postgresql.org; Fri, 30 Jul 2021 02:03:08 +0000 Received: by mail-pl1-x62f.google.com with SMTP id u16so670743ple.2 for ; Thu, 29 Jul 2021 19:03:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=xGQbX2MxLOT527LO5V4DpXZWUUw9qlzGQRk8kwMUJ34=; b=rgj5LAqHKnysuo7bXZi6JTnbVVsTdvcg+8eeOa9H1SpcyHjVljZ5CVNOQ1FpatY6YE 3V50MKRfpPNqIRE/CmfV3K1/THEstqxVxqZwhKOtWBgUqi/trIaKTrV2K6xV0EpXzXac d6Z+WByfBkaFq/PLK8wIa1Wb3qYr6nJRCHgLckOy1Rujtt7CBPmua6g8iJeZgBBZfnhc 1XgjPkhGZ0lB3rhz6hH90OXWrgWVnuNMNxFw7qIj3vyBpPR/PNBWLnLGLgf3e0C/cqF4 i8/BpFzjqffpLhjAErFaMRsoRrZAO2Janizc95PUdRL9/AFauZvYdB+6PsVjIeaShCXo gBmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=xGQbX2MxLOT527LO5V4DpXZWUUw9qlzGQRk8kwMUJ34=; b=DxOcmQwHG/diVj+yIybO9AKKRnUD0zxPBKKgXkWDlOHBbT1qCu4TS0GdqswPyRYvQM QBIeUMFH5eKELewdIlOtkMvFaeTfCSYbm61DeXcvTa5fcogKbOs7w/K/iLc+NIQtDg2O hCtXkikrlwTDVH33otQ2R/kz754i4khln9mcnBD0nz20ZS4Hf1tZU/uDAPTR9N64XvYj XRex2cMcyrLkpSmRHA7rW0sX0ouAWv9FNmUcLhR41w8cg9rNc403H3urj4Aa8A+X/tna N7OYU+V93zYinJDEeUDx4KXDzny0wmQXt1X2coFew/c4umXo3kYcByNGR4hc0VXB/7xX ajkQ== X-Gm-Message-State: AOAM530cLlPKITJ/Hc8CZvjK3q2rVwLghqvJ4Hkh+NZYaX+09pm6j7rP DF3stPA3/rC/M2hoSuVIjxs= X-Google-Smtp-Source: ABdhPJy8zd2ViKuj1mQqMd+noQvtzaInYFk/mGJ1wWTt+aCOaG1qnURg9A7rElCc/rzrRXaU9wQdnw== X-Received: by 2002:a62:170c:0:b029:3a9:c5ce:23b7 with SMTP id 12-20020a62170c0000b02903a9c5ce23b7mr495566pfx.40.1627610584983; Thu, 29 Jul 2021 19:03:04 -0700 (PDT) Received: from nol (2001-b011-0001-1ee1-3704-47f4-8ef2-c9c1.dynamic-ip6.hinet.net. [2001:b011:1:1ee1:3704:47f4:8ef2:c9c1]) by smtp.gmail.com with ESMTPSA id mu9sm174081pjb.26.2021.07.29.19.03.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Jul 2021 19:03:04 -0700 (PDT) Date: Fri, 30 Jul 2021 10:02:57 +0800 From: Julien Rouhaud To: Jan Wieck Cc: Bruce Momjian , PostgreSQL Hackers Subject: Re: pg_upgrade does not upgrade pg_stat_statements properly Message-ID: <20210730020257.jpvunvworyqsaz43@nol> References: <20210729015236.GD9600@momjian.us> <20210729145640.GE9600@momjian.us> <20210729151017.GG9600@momjian.us> <20210729161432.GN9600@momjian.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 Thu, Jul 29, 2021 at 02:14:56PM -0400, Jan Wieck wrote: > > I presume that pg_upgrade on a database with that extension installed would > silently succeed and have the pg_catalog as well as public (or wherever) > version of that function present. I'll have to run a pg_upgrade with it to be 100% sure, but given that this is a plpgsql function and since the created function is part of the extension dependencies (and looking at pg_dump source code for binary-upgrade mode), I'm almost certain that the upgraded cluster would have the pg96- version of the function even if upgrading to pg9.6+. Note that in that case the extension would appear to work normally, but the only way to simulate missing_ok = true is to add a BEGIN/EXCEPTION block. Since this wrapper function is extensively used, it seems quite possible to lead to overflowing the snapshot subxip array, as the extension basically runs every x minutes many functions in a single trannsaction to retrieve many performance metrics. This can ruin the performance. This was an acceptable trade off for people still using pg96- in 2021, but would be silly to have on more recent versions. Unfortunately I don't see any easy way to avoid that, as there isn't any guarantee that a new version will be available after the upgrade. AFAICT the only way to ensure that the correct version of the function is present from an extension point of view would be to add a dedicated function to overwrite any object that depends on the servers version and document the need to call that after a pg_upgrade.