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 1nzAXn-00068b-Lv for pgsql-bugs@arkaria.postgresql.org; Thu, 09 Jun 2022 05:17:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nzAXm-0004Fo-FR for pgsql-bugs@arkaria.postgresql.org; Thu, 09 Jun 2022 05:17:18 +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 1nzAXm-0004Ff-6z for pgsql-bugs@lists.postgresql.org; Thu, 09 Jun 2022 05:17:18 +0000 Received: from mail-ot1-x335.google.com ([2607:f8b0:4864:20::335]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nzAXj-0005aY-U1 for pgsql-bugs@lists.postgresql.org; Thu, 09 Jun 2022 05:17:17 +0000 Received: by mail-ot1-x335.google.com with SMTP id g13-20020a9d6b0d000000b0060b13026e0dso16599232otp.8 for ; Wed, 08 Jun 2022 22:17:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leadboat.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=TLa5mR1SekHvyJWHQO/STomA6VEvb1EyomI7+6dhN48=; b=JySjpDE9YzbHmUYaek6aXJm79kRu1TRHgN3Fwi8k8Nphb9caS0vKfzaGUFREmEP1c6 QeIQJRQ0SV6KbSyPxx2AFVgDdgorndJj+aj80ni6ctXM1CChItkMSbp+xpdddXaQqmHx UOynBRRcZSV/bA+XVmx1Pjq0uiaSBpGKNJ9BI= 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=TLa5mR1SekHvyJWHQO/STomA6VEvb1EyomI7+6dhN48=; b=JgCIifT1ZUf44HmLrOi8UOmOA74JRGHhdWcNUiSmI/iII1gPPpHdN5Ek9IOnz2AHb3 w8xxwhetJ19BujTYdsFZ5tELbNYIWaL8cEh37gjW4bJsyfX5IshvJk6uPVgobSz+6IPb msSLR/n8m5ZrxwU7vAkYvgOElSPGjK9Ch01FneGELxY3QYfTHiOce4U/eb7zXfoTeL8t 9IcEiWZtD+xyrqzDfDqtW1w9lnyl8tHG+dYtTQKDrTVqrl0HiTKltCQ7h7z2Vq9cqx7M uDKapYJIM1QsOe3yU7wmK5VvJtbgz2mscTf6/118+mOQiPzXEAWRlYHKmheqqJTEbu7t cy3w== X-Gm-Message-State: AOAM531rtyz9FRnP6votQ0gFreMCieThNukXzpGxGHwXLNfHetPbDOD7 jR3gA+Zi/pMK/v/4tbf76M04dw== X-Google-Smtp-Source: ABdhPJx/8Bz1+pCMXrVgkIiX3QWRS6ydAYlrtDMxuBQoHOPDP9td2APHRf+5yP29aGCyOb0X5vNRkA== X-Received: by 2002:a9d:6552:0:b0:605:e866:1b58 with SMTP id q18-20020a9d6552000000b00605e8661b58mr15997302otl.224.1654751832164; Wed, 08 Jun 2022 22:17:12 -0700 (PDT) Received: from rfd.leadboat.com ([2600:1702:a20:5750::2e]) by smtp.gmail.com with ESMTPSA id j9-20020a056870530900b000f33b23a030sm10236346oan.57.2022.06.08.22.17.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jun 2022 22:17:11 -0700 (PDT) Date: Wed, 8 Jun 2022 22:17:08 -0700 From: Noah Misch To: Nathan Bossart Cc: Michael Paquier , pgsql-bugs@lists.postgresql.org, =?iso-8859-1?Q?F=E4rber=2C_Franz-Josef_=28StMUK=29?= , Tom Lane Subject: Re: Extension pg_trgm, permissions and pg_dump order Message-ID: <20220609051708.GA3615673@rfd.leadboat.com> References: <1961551.1653498155@sss.pgh.pa.us> <20220526055047.GA3153526@rfd.leadboat.com> <20220528045122.GA3228881@rfd.leadboat.com> <20220529033033.GA1973706@nathanxps13> <20220529043403.GB3265235@rfd.leadboat.com> <20220531152855.GA2236210@nathanxps13> <20220603181724.GA2672350@nathanxps13> <20220606063056.GA3527347@rfd.leadboat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220606063056.GA3527347@rfd.leadboat.com> User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sun, Jun 05, 2022 at 11:30:56PM -0700, Noah Misch wrote: > On Fri, Jun 03, 2022 at 11:17:24AM -0700, Nathan Bossart wrote: > > On Tue, May 31, 2022 at 08:28:55AM -0700, Nathan Bossart wrote: > > > I've spent some time looking at all the code impacted by a117ceb and > > > 0abc1a0, and I've yet to identify any additional problems besides the one > > > with ResolveOpClass(). However, I'm far from confident in this analysis, > > > and I still need to try out the ereport() approach that Noah suggested. I > > > would welcome any assistance identifying other problem areas. > > > > Ah, I think I am missing something. For example, the code that identifies > > the exclusion operator (immediately following the call to ResolveOpClass()) > > is likely subject to a similar problem. > > That would not surprise me. Do you have what you need to continue? I'll use that window on Sunday to review what you have. If you have work in progress, please get it to the mailing list by then.