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 1p38Hm-000142-77 for pgsql-hackers@arkaria.postgresql.org; Thu, 08 Dec 2022 04:13:26 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1p38Hk-0002RC-Hq for pgsql-hackers@arkaria.postgresql.org; Thu, 08 Dec 2022 04:13:24 +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 1p38Hk-0002R2-4I for pgsql-hackers@lists.postgresql.org; Thu, 08 Dec 2022 04:13:24 +0000 Received: from mail-pl1-x636.google.com ([2607:f8b0:4864:20::636]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1p38Hd-0000pk-Do for pgsql-hackers@postgresql.org; Thu, 08 Dec 2022 04:13:23 +0000 Received: by mail-pl1-x636.google.com with SMTP id 4so414904pli.0 for ; Wed, 07 Dec 2022 20:13:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=1gvLd8Lky0xSB4UOgfU+y2XO11rNjhSxdOej0PHV4BI=; b=TlyLdoaLuwYs72Eu87g5KZD2u5xeL2VkKCsj/UlJtL0myaCGghzD/xWoF4jGTWUwnm bKauciLr9pi/Hb/GDvvXOs7eaa6kRp/eqCn3AIqc10nr5XWB20WnXJz94AO7qCSxHMSl PbEuQE/qcDe0eaA+dUiqYDndMQ0yLmuWVbBmamKHoGBohT/lqRVokYj07h6IqEnIMDXR iCbQkjQp6HUtROh50k4bDLBVPdO2KW24qsK/ORfACXbRuVQu3wLwrJwYyys6x5U+JCsY JnkJAVz7n0jEgzRLILUQDWOypXKPI9NeI+lxV5Mgbjm1E0XSVIjqtQCGvW3gDM1MeLkW 4WjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=1gvLd8Lky0xSB4UOgfU+y2XO11rNjhSxdOej0PHV4BI=; b=I1bbLhk6/XQ4VElskpqK3MJ4Ct35RnxKkm95nA39kpE21a7jusC3q7o9n/BtZB4WT5 SUI5d31sbm5zJcAH53b5wuBERjio1V89AoyjM6UeVNS1Ks65ANZoPJg+Lx/bdMOp7gUJ PH8N4dtHaCX83lPrWc63cToR/4s/GxRXSuhojs3AvLXmyAB6Z68rMYMyFUIKe6l2E+eU 9KQJ2JFgCvQdVHnGo6K1dEUMPBb4ThdYPxQ9kXAK7bqY33YpmBzZN84BvWvu7WXKZfoa 3ZuqNer3qOX2+wINcz+Yebh8qeVc9D+P2awxU1gbxWIFnrTGCb6wunlwQAJxj551mLl0 c/Ow== X-Gm-Message-State: ANoB5plytsOQDXrGYX//OBkDJ4pFjwAwvMTKA6W6UeYO2VMJOkNM++pY wRqZHsdbu1/rNQdRp34Le2M= X-Google-Smtp-Source: AA0mqf5ALu6tR9UIh+LhE2EFm0g+rD+Wl95xC1/optSYoT0REh87WAtyFFigoTniugokO4RgXFQU3Q== X-Received: by 2002:a17:90b:4ccf:b0:21b:99ea:cde5 with SMTP id nd15-20020a17090b4ccf00b0021b99eacde5mr2021214pjb.149.1670472796102; Wed, 07 Dec 2022 20:13:16 -0800 (PST) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id 207-20020a6216d8000000b00575caf8478dsm4143703pfw.41.2022.12.07.20.13.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Dec 2022 20:13:15 -0800 (PST) Date: Wed, 7 Dec 2022 20:13:13 -0800 From: Nathan Bossart To: Justin Pryzby Cc: pgsql-hackers@postgresql.org Subject: Re: fix and document CLUSTER privileges Message-ID: <20221208041313.GA216874@nathanxps13> References: <20221207223924.GA4182184@nathanxps13> <20221208022559.GA27893@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221208022559.GA27893@telsasoft.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Dec 07, 2022 at 08:25:59PM -0600, Justin Pryzby wrote: > Your patch makes it inconsistent with vacuum full, which is strange > because vacuum full calls cluster. > > postgres=> VACUUM FULL t; > VACUUM > postgres=> CLUSTER t; > ERROR: must be owner of table t This is the existing behavior on HEAD. I think it has been this way for a while. Granted, that doesn't mean it's ideal, but AFAICT it's intentional. Looking closer, the database ownership check in get_tables_to_cluster_partitioned() appears to have no meaningful effect. In this code path, cluster_rel() will always be called with CLUOPT_RECHECK, and that function only checks for table ownership. Anything gathered in get_tables_to_cluster_partitioned() that the user doesn't own will be skipped. So, I don't think my patch changes the behavior in any meaningful way, but I still think it's worthwhile to make the checks consistent. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com