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 1pGQkH-0005Gk-GA for pgsql-hackers@arkaria.postgresql.org; Fri, 13 Jan 2023 20:33:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pGQkE-0007Vd-W5 for pgsql-hackers@arkaria.postgresql.org; Fri, 13 Jan 2023 20:33:46 +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 1pGQkE-0007VT-L4 for pgsql-hackers@lists.postgresql.org; Fri, 13 Jan 2023 20:33:46 +0000 Received: from mail-pj1-x1029.google.com ([2607:f8b0:4864:20::1029]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pGQk7-00058Z-PM for pgsql-hackers@postgresql.org; Fri, 13 Jan 2023 20:33:46 +0000 Received: by mail-pj1-x1029.google.com with SMTP id v23so23519146pju.3 for ; Fri, 13 Jan 2023 12:33:39 -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=IpI7Wy4BOXv6ZEnQ/Q+NwWGnE2rkOt3ax71nWd71+CI=; b=AMd/Y11M4f8gz/z8jsX8yM5VMLu0JW9PFjDy2ykjDfJaWUJFD46m4bB50uc6zDcVht 4ufPHzr8piYJBHh8hkFVLYFDrvgkpWedIBbn4t8ix6HDb8e68ISfIQOFPBMl5Euzobtz Oh18zoKU/fd2cImHI/rpx/tACnBQOau92W5Kvw+WdG7HxVq/U946pctY/CipPtqPJ3GL S3GuzwCYti5RRrzYZZBrb9Z11Ki5nJDz2raGA5excQqE+eBScBvIfxqfHJ063S3keon+ jddqyoZ+MzMFAUOkABQfwLYhF1CZXs0yldBppj2StQ+W3AT4Y1DBohPUTz720YrLqDl7 imcg== 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=IpI7Wy4BOXv6ZEnQ/Q+NwWGnE2rkOt3ax71nWd71+CI=; b=SYaCgz9S2odeYBPRjY4Jyj/u+29et9lFhF64LhKRX8WgYtnnD4PhrXPeE+4ofQqa3J +SBJMZ0CjnUfdjTHkJJaJLB1HYe0Bdz5lkltXIv4QtyakboZYDqK37Dnkjttd4nfLeKw XZ1ebrEdOw72QtubWrCR8OzGDnjlFIfSuUpPIQH5wXUjBNCzKYEO4M6legdfSrxv8axa JIaSyY8k+gII2DqzJfd7zPjBnoxGim4f2H+SVogs4+EWturZSALRjgi569Mn+RqE0UWG I2TOmv5Z7qqHyeVWSKYaiw3PWNk2nF5/HGENr3oWf+b06M8Pbf27BAn8HV5A75PBIDkO 3QEQ== X-Gm-Message-State: AFqh2kqLjzdD1cmp5QDrIdNyA1l2dyxOAkEyvnhPOXdjGng0uzytI0Bq R7EC5niHtHkdcK3L3cSQ1Gg= X-Google-Smtp-Source: AMrXdXuwkcP1a0FiTEd9oHmeVXfy5w8YXDre4uYt0rpiC5e+n6qTUHAyxM96JoFBPfNFipzbvzLlJg== X-Received: by 2002:a05:6a20:d48a:b0:b6:1413:6b68 with SMTP id im10-20020a056a20d48a00b000b614136b68mr18691299pzb.46.1673642016873; Fri, 13 Jan 2023 12:33:36 -0800 (PST) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id o33-20020a17090a0a2400b00226463cd239sm14624767pjo.15.2023.01.13.12.33.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Jan 2023 12:33:36 -0800 (PST) Date: Fri, 13 Jan 2023 12:33:34 -0800 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: <20230113203334.GA2206335@nathanxps13> References: <20221214221140.GA1153@telsasoft.com> <295e86c7aeafb8e2623f8eccdc846855bf2c7e0c.camel@j-davis.com> <20221217060408.GA1256247@nathanxps13> <20221218233018.GA1476904@nathanxps13> <20230103234549.GA289060@nathanxps13> <20230109225157.GA1288965@nathanxps13> <7d2a8b72e23c8236281c6e00ae790327f965a8e5.camel@j-davis.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7d2a8b72e23c8236281c6e00ae790327f965a8e5.camel@j-davis.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, Jan 13, 2023 at 11:56:03AM -0800, Jeff Davis wrote: > I'm hesitant to add an index to pg_class just for the privilege checks > on toast tables, and I don't think we need to. I bet this index will be useful for more than just these privilege checks (e.g., autovacuum currently creates a hash table for the toast-to-main-relation mapping), but I do understand the hesitation. > Instead, we can just > skip the privilege check on a toast table if it's not referenced > directly, because we already checked the privileges on the parent, and > we still hold the session lock so nothing strange should have happened. That would fix the problem in the original complaint, but it wouldn't allow for vacuuming toast tables directly if you only have MAINTAIN privileges on the main relation. If you can vacuum the toast table indirectly via the main relation, shouldn't it be possible to vacuum it directly? -- Nathan Bossart Amazon Web Services: https://aws.amazon.com