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 1o21IO-0003pm-B7 for pgsql-hackers@arkaria.postgresql.org; Fri, 17 Jun 2022 02:01: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 1o21IN-0005kM-8y for pgsql-hackers@arkaria.postgresql.org; Fri, 17 Jun 2022 02:01:11 +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 1o21IM-0005kC-OV for pgsql-hackers@lists.postgresql.org; Fri, 17 Jun 2022 02:01:11 +0000 Received: from mail-il1-x12c.google.com ([2607:f8b0:4864:20::12c]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1o21IH-0006Ho-F2 for pgsql-hackers@lists.postgresql.org; Fri, 17 Jun 2022 02:01:09 +0000 Received: by mail-il1-x12c.google.com with SMTP id p1so2105006ilj.9 for ; Thu, 16 Jun 2022 19:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=BYMX1NanFkIrinpFnYDGD/6KhcApme4g6WtMHNCD7iA=; b=UbLeqShLXhSLcCMEGkgWDikI0iqhkbLRPKzvBRnBSrn5X0YUurCaegpY129dhzpgDR xK7b0Yj3quxBfFcIOr5uPr/uzsiN2M7cNXzHrdbsyaTcEjoK9cxqV949W33nxr+XpVuJ UPCXJM7LbOmx00zNSHVOi0czuSS8UL8kZamohh2DWtIe7AVcW+kOafhIdc+h4BBLWldP bYmuzAblsD6Pk76XDsI6+AsiUss3SrVIxR3R9O56GQ7H9bYalIoMIwkOsECOx1deph99 ic60JDtpMOM4cJl3T84E79oMLHjR6cyPCbn4BqfL7aqW39DB5AC3Z7kGskF5IuUAat4Y GH4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=BYMX1NanFkIrinpFnYDGD/6KhcApme4g6WtMHNCD7iA=; b=ioqVzEbsWCWvdz1Ur9GenpMzEBfcyrLVgaFHZTgITaIZGOruG+zbLAvtFBa8oUqr5e SUiRiHv+lUGi9NpJAnlrUs0mExem+PiVQ9UrA+ImV6yPuGAMCW3g27atcJuhC6fxBUVg rjar2TPCnKBM4/+EsyVyu+8GLnXzrjYd2OgqVz5TkGwpXmsyKfl57Q4mpK+yUZFF+Qt+ 6DSfyXgBgKcR+2MadeOBu9KzC91vi8E07UkKbGsP7MFr84XyoSg1o4JZnzCXQXIptI8C VqXNAfbqa6OFbfn8rWYpM5LbdyJzailgq5qFtw9sVi0weL7XtazwCpOvikcANzLJ0Fqi ChXQ== X-Gm-Message-State: AJIora9dYnTWekZcxigHInj5IKU+bG323OkLe71F9qXENy9h3y0jJl+R BsHhpl3g+jFkzBhaYy33SRNlFg== X-Google-Smtp-Source: AGRyM1svuU6QRDkGuAgAcJt1OX5aM9jVk2oc+CKUhOmxx0T9e0QzxyLRD1uDxvuS+1F8eftvqTgpmQ== X-Received: by 2002:a05:6e02:1b0d:b0:2d1:ce6b:df4c with SMTP id i13-20020a056e021b0d00b002d1ce6bdf4cmr4292573ilv.109.1655431264530; Thu, 16 Jun 2022 19:01:04 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id a3-20020a924443000000b002d3b759dc7fsm1688286ilm.77.2022.06.16.19.01.03 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Jun 2022 19:01:03 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 41DCA800B00; Thu, 16 Jun 2022 21:01:03 -0500 (CDT) Date: Thu, 16 Jun 2022 21:01:03 -0500 From: Justin Pryzby To: Tom Lane Cc: "David G. Johnston" , Petr Vejsada , pgsql-hackers@lists.postgresql.org Subject: Re: pg_upgrade (12->14) fails on aggregate Message-ID: <20220617020103.GG29853@telsasoft.com> References: <3383880.QJadu78ljV@vejsadalnx> <20220614230949.GX29853@telsasoft.com> <540147.1655321524@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="UfEAyuTBtIjiZzX6" Content-Disposition: inline In-Reply-To: <540147.1655321524@sss.pgh.pa.us> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --UfEAyuTBtIjiZzX6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jun 15, 2022 at 03:32:04PM -0400, Tom Lane wrote: > Justin Pryzby writes: > > But Petr has a point - pg_upgrade should aspire to catch errors in --check, > > rather than starting and then leaving a mess behind for the user to clean up > > Agreed; pg_upgrade has historically tried to find problems similar to > this. However, it's not just aggregates that are at risk. People > might also have built user-defined plain functions, or operators, > atop these functions. How far do we want to go in looking? I wasn't yet able to construct a user-defined function which fails to reload. > As for the query, I think it could be simplified quite a bit by > relying on regprocedure literals, that is something like Yes, thanks. > Also, I think you need to check aggfinalfn too. Done but maybe needs more cleanup. > Also, I'd be inclined to reject system-provided objects by checking > for OID >= 16384 rather than hard-wiring assumptions about things > being in pg_catalog or not. To me, oid>=16384 seems more hard-wired than namespace!='pg_catalog'. This patch also resolves an issue with PQfinish()/dangling connections. -- Justin --UfEAyuTBtIjiZzX6 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0001-WIP-pg_upgrade-check-detect-old-polymorphics-from-pr.patch"