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 1q9BJz-0002Me-2D for pgsql-hackers@arkaria.postgresql.org; Tue, 13 Jun 2023 21:12:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1q9BJx-0004yV-Ng for pgsql-hackers@arkaria.postgresql.org; Tue, 13 Jun 2023 21:12:57 +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 1q9BJx-0004xS-EV for pgsql-hackers@lists.postgresql.org; Tue, 13 Jun 2023 21:12:57 +0000 Received: from mail-pf1-x42f.google.com ([2607:f8b0:4864:20::42f]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1q9BJq-0022G0-Jd for pgsql-hackers@postgresql.org; Tue, 13 Jun 2023 21:12:56 +0000 Received: by mail-pf1-x42f.google.com with SMTP id d2e1a72fcca58-651f2f38634so6037554b3a.0 for ; Tue, 13 Jun 2023 14:12:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686690769; x=1689282769; 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=Yg+NR1UUsiHzFL5fT3FYmMxfC2SFhk7thyUJygnozlY=; b=WuRwTHq23WEnjGw0PyRXdJSi11jAcfarh1X+kNnAyiPV6aUbss8aIHdhVOdmwQObTa idhuIfgz5yCzfg4e9sXLIc2SpDO+gdDt89bukGQMK65UyNnRuqDqV8erxkg/k7ww4cWF N8QwWSVoAIzysb1X/kTLN31MApyMdtIOfJ1QYdpQd/sZEafgI3xLGMw0TYjPiKo4pZSl +RhJqJWes1kEfMqSGCjIwKupLOFJjszPz5u8F/wuWURKP+Sn/1ahBOFP/i8yLAcARUOH /WvIv5D0GbnUkT2HPWeTNY+DkU5GDBF3Pc/9fFzW2ts7KYaj6NTuIfYiU1JLWhILU+yF 5EcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686690769; x=1689282769; 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=Yg+NR1UUsiHzFL5fT3FYmMxfC2SFhk7thyUJygnozlY=; b=GQeShyviFpYGsnwT5/2kRHQjV9Yp+Kc8UUNk5gBjhLEz9RVIoGi4dnMmUv/TrvxZ0S E58VbLxRzomPVymDSlu7Mvz/C2SvOsVI0+Sc3wiNnOf04E6IBeQcLFLKlEJjKbtpv/6L bjHjKM4FkxZLzM4wJafgSyod3ou0hb3Y456XFPkmo8PI94a7lzuIilgcCx/s7Jt7xJH9 Hn/k3IFOasONPW61DmD9NSqnlf0no8mFEb3kUGpPfG7ZADtRlc5guy8UPEQ17+BLCGyQ ZXD23jooGO484orf7RaNUwdBRv+3CeHBu6ewXFL5dxI9ZPpwFIdPTHDNpyfbVFKHTwDR dqNw== X-Gm-Message-State: AC+VfDw1apyyBYQfvqnW+mBiVQjCB8hZM8k2TGeGTd3pkq22NX3XiFTo euqED7tOQUMEwwlJzK3Ei9U= X-Google-Smtp-Source: ACHHUZ7VS2MJ1HvBqX4+odCwJBh2bGTRsnfwnx0JwFDMqUJ3ByAHWg4e4MgG3NpV5LjxJ19/J1JomA== X-Received: by 2002:a05:6a00:80d:b0:659:61ba:62df with SMTP id m13-20020a056a00080d00b0065961ba62dfmr18463712pfk.27.1686690769552; Tue, 13 Jun 2023 14:12:49 -0700 (PDT) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id h7-20020a62b407000000b00637b0c719c5sm9000472pfn.201.2023.06.13.14.12.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Jun 2023 14:12:48 -0700 (PDT) Date: Tue, 13 Jun 2023 14:12:46 -0700 From: Nathan Bossart To: Jeff Davis Cc: Ted Yu , Pavel Luzanov , Justin Pryzby , pgsql-hackers@postgresql.org Subject: Re: allow granting CLUSTER, REFRESH MATERIALIZED VIEW, and REINDEX Message-ID: <20230613211246.GA219055@nathanxps13> References: <20221217060408.GA1256247@nathanxps13> <20221218233018.GA1476904@nathanxps13> <20230103234549.GA289060@nathanxps13> <20230109225157.GA1288965@nathanxps13> <7d2a8b72e23c8236281c6e00ae790327f965a8e5.camel@j-davis.com> <20230113203334.GA2206335@nathanxps13> <20230113225626.GA2380176@nathanxps13> <20230113231339.GA2422750@nathanxps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230113231339.GA2422750@nathanxps13> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk I've been reviewing ff9618e lately, and I'm wondering whether it has the same problem that 19de0ab solved. Specifically, ff9618e introduces has_partition_ancestor_privs(), which is used to check whether a user has MAINTAIN on any partition ancestors. This involves syscache lookups, and presently this function does not take any relation locks. I did spend some time trying to induce cache lookup errors, but I didn't have any luck. However, unless this can be made safe without too much trouble, I think I'm inclined to partially revert ff9618e, leaving the TOAST-related parts intact. By reverting the partition-related parts of ff9618e, users would need to have MAINTAIN on the partition itself to perform the maintenance command. MAINTAIN on the partitioned table would no longer be sufficient. This is more like how things work on supported versions today. Privileges are checked for each partition, so a command that flows down to all partitions might refuse to process a partition (e.g., if the current user doesn't own the partition). In the future, perhaps we could reevaluate adding these partition ancestor privilege checks, but I'd rather leave it out for now instead of introducing behavior in v16 that is potentially buggy and difficult to remove post-GA. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com