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 1p5tf6-0007Jw-MW for pgsql-hackers@arkaria.postgresql.org; Thu, 15 Dec 2022 19:12:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1p5tf5-0006BS-4O for pgsql-hackers@arkaria.postgresql.org; Thu, 15 Dec 2022 19:12:55 +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 1p5tf4-0006BJ-Pp for pgsql-hackers@lists.postgresql.org; Thu, 15 Dec 2022 19:12:54 +0000 Received: from mail-pl1-x62e.google.com ([2607:f8b0:4864:20::62e]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1p5tf0-0000RZ-PX for pgsql-hackers@postgresql.org; Thu, 15 Dec 2022 19:12:54 +0000 Received: by mail-pl1-x62e.google.com with SMTP id t2so7890025ply.2 for ; Thu, 15 Dec 2022 11:12:50 -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=rNiME968cEmmmyZBQxv7ns+CtGnosSG2qfzLgEQoeeE=; b=VV9yZCfxVtju6C3ev4tMuie/oYjGOFjE23Crw1HR3gyDsE4NBOLpWbW3ZgPw8T+a72 UDzlPpjk1mKuh5XanHwISAZMDJtO2k0oKeHqYmUZGe+eEyxgOsHnRVQ8bCi+wlCh4oBe 6FRKqhUj6Q5ef257YyGXk5faPX4PphHEqAkebuBg9A5nhcviMVsA5znWfyFQ6iSLJt+n GgzPPlkLljYK51rOBQtx3WWuZNVw31s0UFufCViadT/Z9TzRnn1ccfNHTnHniHXp64cV FMWmS6f4Kzb91r1+yn5cixhnYVdHlVp6F/mLMOaHh7pIHEYlBSp6Mw5OsUXjR12aXOD7 AH8A== 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=rNiME968cEmmmyZBQxv7ns+CtGnosSG2qfzLgEQoeeE=; b=kD+aw9I9YDOzNPHCD6VF56UVtluAh2MVfgpCJdMbqMSUUSZKGbPVDHTwE4im/yqG8q dBii0TlrfXeer7lMfiMbYwueH2pU5sGbYi93WX9Xdj/6RIPOtb8TdeK5AReUWywIBbfO KPxkEPnuHQBskEwQ0YbniJZFlleVNEB+J6VxcM0KGiSB2G4EpnUn2w2Wr75+iYeC8zv/ RJCowkyWzcUxb4F3xP72cbSzUYxgEtDzul/ay8GaxkgxKulBuIjKU8ltC/wvmPnCREMu whBBBXxEA+XowTwpp84+0qDKrRJY+hR8D7ikTzoAl+BRZLV0MPkYtjQJfUB2CzHOPR7B Zeyg== X-Gm-Message-State: ANoB5pmB2bPbqeBGoJRLXPnqjHNSQparrsiYKwU0fg/EjtO6lO5LarJw B4a1zE5bLSGVJTxQJ6eI4wM= X-Google-Smtp-Source: AA0mqf68BmhHCG0ZEAypiZ0DIZ9DLOevB53l5W41hC8dItgaotEOKM4jdQA5ljB82XZF5DN8UDHVPg== X-Received: by 2002:a05:6a21:2d84:b0:a4:7077:5bf5 with SMTP id ty4-20020a056a212d8400b000a470775bf5mr36450072pzb.4.1671131568666; Thu, 15 Dec 2022 11:12:48 -0800 (PST) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id t19-20020a170902b21300b001782a6fbcacsm3447plr.101.2022.12.15.11.12.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Dec 2022 11:12:48 -0800 (PST) Date: Thu, 15 Dec 2022 11:12:46 -0800 From: Nathan Bossart To: Jeff Davis Cc: Michael Paquier , Alvaro Herrera , Pavel Luzanov , pgsql-hackers@postgresql.org Subject: Re: allow granting CLUSTER, REFRESH MATERIALIZED VIEW, and REINDEX Message-ID: <20221215191246.GA252861@nathanxps13> References: <20221214171336.GB689106@nathanxps13> <20221214180534.jglo7jclow3x73bd@alvherre.pgsql> <20221214181659.GB773264@nathanxps13> <20221214232939.GA828727@nathanxps13> <20221215002705.GA889413@nathanxps13> <8f63ff5b9188004c8e439ac16e92adf3266169b9.camel@j-davis.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8f63ff5b9188004c8e439ac16e92adf3266169b9.camel@j-davis.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, Dec 15, 2022 at 10:42:15AM -0800, Jeff Davis wrote: > Right now, targetting the toast table directly requires the USAGE > privilege on the toast schema, and you have to look up the name first, > right? As it is, that's not a great UI. > > How about if we add a VACUUM option like TOAST_ONLY (or combine it with > the PROCESS_TOAST option)? Then, you're always looking at the parent > table first so there's no deadlock, do the permission checks on the > parent, and then expand to the toast table with no check. This can be a > follow-up patch; for now, the idea of skipping the privilege checks > when expanding looks like an improvement. I originally suggested an option to allow specifying whether to process the main relation, but we ended up only adding PROCESS_TOAST [0]. FWIW I still think that such an option would be useful for the reasons you describe. [0] https://postgr.es/m/BA8951E9-1524-48C5-94AF-73B1F0D7857F%40amazon.com -- Nathan Bossart Amazon Web Services: https://aws.amazon.com