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 1qBfU0-0003uj-5B for pgsql-hackers@arkaria.postgresql.org; Tue, 20 Jun 2023 17:49:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1qBfTz-0006xE-4W for pgsql-hackers@arkaria.postgresql.org; Tue, 20 Jun 2023 17:49:35 +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 1qBfTy-0006x4-Ry for pgsql-hackers@lists.postgresql.org; Tue, 20 Jun 2023 17:49:34 +0000 Received: from mail-oa1-x32.google.com ([2001:4860:4864:20::32]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qBfTv-003fNq-VN for pgsql-hackers@postgresql.org; Tue, 20 Jun 2023 17:49:34 +0000 Received: by mail-oa1-x32.google.com with SMTP id 586e51a60fabf-1aa291b3fc7so2157991fac.1 for ; Tue, 20 Jun 2023 10:49:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687283370; x=1689875370; 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=DY/F8V+2pbAgB0XuaWzP3NlJv5O6X/e87UUgt43innM=; b=gkTHLuRuSBV4kG/z68uon06rO48aAH6vWY7U7KO5XT77D57b24Fg31pWN0ZmJhEY0W jJ284G+bEAa/4sPuX2l9xg9hhMVyS5LGnPz6cBoUWDuuSiKuK4QbzdGDZX3SObmVpodM I6jojHPgujZNY1wCkR1RWJpQt426vOPf0tJ2rq9ehK520ZiWWdXq3HILbGB4rfNh6qge dOeswgcLcpwKaLiTJ3KKa9LVtAFKvh00E8E/A/1YQgcId7Z4OVfB51DfZWq2NWB5Dsh3 P1/Pi/kbQ4mdpV/u1dfvfW9D0nZYq7JpoQaQG3yZgUoBuRSvW7kH2PTjTVK3PUiy7/vq cg7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687283370; x=1689875370; 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=DY/F8V+2pbAgB0XuaWzP3NlJv5O6X/e87UUgt43innM=; b=bXEA+36u0lZhZRn9f7DZF81y9THB1Yp9z2tPn5609kNRAUu17I00sBzDufOWfUt5mk iu/Ro4kN4kIBzJ/4pd8R6LqWF1lIFKDj0QD1lKW3WquDhafps/RIxSlL46SwImhgSfdq DIPZa8U8vWK834TO00xjIRfzeWSZWKcBBRLrto6ICDOhtCDk6VHMgT1ojcD/AiI6Ah/q ao/AwBluIZLNS40cn2rZhYOCAFv167wL2AZVqeyLkX/rLoMenDVcbBsuiiBEMVe+5ybD h23lL3uojT/A3+kEup4C864rs//I+J2dGLrfRVXyNQLX1yL3eJ/BtP4by1IkY+AU+MQ9 /LTA== X-Gm-Message-State: AC+VfDzy8cVjpmoyb9b/iyvzZ4W18muh7oJW1AK0w1ETzV7HhaBO2NiV UHBvSXYqk7X36x5EzXbhH1o= X-Google-Smtp-Source: ACHHUZ577v4Toh4e/AsfG7kVd97vCOcsTPvVPln/hKyfWSkrNWGic/8SbHEHcD8PUlJjHfapeJbE3A== X-Received: by 2002:a05:6870:c806:b0:1a3:16af:56e2 with SMTP id ee6-20020a056870c80600b001a316af56e2mr8968236oab.19.1687283369919; Tue, 20 Jun 2023 10:49:29 -0700 (PDT) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id r21-20020a63e515000000b0054f9936accesm1679178pgh.55.2023.06.20.10.49.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Jun 2023 10:49:29 -0700 (PDT) Date: Tue, 20 Jun 2023 10:49:27 -0700 From: Nathan Bossart To: Jeff Davis Cc: Michael Paquier , Ted Yu , Pavel Luzanov , Justin Pryzby , pgsql-hackers@postgresql.org Subject: Re: allow granting CLUSTER, REFRESH MATERIALIZED VIEW, and REINDEX Message-ID: <20230620174927.GA494037@nathanxps13> References: <20230613235442.GA222795@nathanxps13> <20230614181711.GA488295@nathanxps13> <20230615041044.GA736001@nathanxps13> <20230615235700.GA877311@nathanxps13> <20230616052025.GA1026700@nathanxps13> <20230619215534.GA442477@nathanxps13> <20230620174032.GA471329@nathanxps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230620174032.GA471329@nathanxps13> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Jun 20, 2023 at 10:40:32AM -0700, Nathan Bossart wrote: > On Tue, Jun 20, 2023 at 10:04:37AM -0700, Jeff Davis wrote: >> I think v4-0001 broke the handling of toast tables? It looks like you >> removed the check for !skip_privs but need to add it to the flags in >> vacuum_is_permitted_for_relation(). > > Good catch. I'm not sure why some of the calls to > vacuum_is_permitted_for_relation() are masking the options. AFAICT we can > simply remove the masks. I've done so in the attached patch. Oh, I think I see why. This appears to be used to control which WARNING message is emitted. If you lose permissions before you get to analyzing in a VACUUM (ANALYZE) command, you'll get a "permission denied to vacuum" message instead of a "permission denied to analyze" message. IMO a better way to do that would be to control only those two bits (VACOPT_VACUUM and VACOPT_ANALYZE) in calls to vacuum_is_permitted_for_relation(), and to leave the rest untouched. Patch incoming... -- Nathan Bossart Amazon Web Services: https://aws.amazon.com