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 1pD3lk-0003cr-Sn for pgsql-hackers@arkaria.postgresql.org; Wed, 04 Jan 2023 13:25:25 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pD3lj-0005zj-GV for pgsql-hackers@arkaria.postgresql.org; Wed, 04 Jan 2023 13:25:23 +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 1pD3lj-0005zZ-5f for pgsql-hackers@lists.postgresql.org; Wed, 04 Jan 2023 13:25:23 +0000 Received: from mail-wm1-x32e.google.com ([2a00:1450:4864:20::32e]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pD3lc-0008Cl-69 for pgsql-hackers@postgresql.org; Wed, 04 Jan 2023 13:25:21 +0000 Received: by mail-wm1-x32e.google.com with SMTP id k22-20020a05600c1c9600b003d1ee3a6289so26393374wms.2 for ; Wed, 04 Jan 2023 05:25:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=migops.com; s=google; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=L+duTS29+HaRgqs3ihs4hPtE+qyFQvxpdR0RSUGlZKk=; b=RcyOR9ID5hWis0Quuz9Cqe2AfLISXB8ZCI/IhkA1QWib6PnanRyHjOcCpgqEcfXlem etRLY2sL6Yiay2+N8u0NrJTU2DH0tf4v6J9rXvRXHUEMnPqrpfEAnGnvTW889FQyr91p 5tyXTM1a+5rUgNHzAhuG4yEyir/RBcBn3ZfEkUZ2e1bT3cVFJa8KZHPCPWTARCxy0lNP I/RQuXOfMEd7c11aBVnmKnGt14pqtBvTrq62EmcFFO5UufeN8ycOn7JXlKohL72+T33j 3+jvPcWM5NBcOjmEFLlnWzZC0X5Sa2Eau0G7iWE2BpfVmomdcjTs0nGj49qdqJ5lk9Ac tzEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=L+duTS29+HaRgqs3ihs4hPtE+qyFQvxpdR0RSUGlZKk=; b=SzH9cmFptocmk4MT+qHa5BeBs9gfi4nf520rVVZWccuP1g6VeSBbFHzMAyURJvwo6q TtP5LwU68UI4eMLB2zL4s+eDuVbKTdYk2BRhieHOaM6IUEr/epUm7rngIUsGDC5dGq0e F73o+8OUjaZAQSsPsqdGEPB/4ntqNquoGwJByf5KIi/Lilbpgj3N6iegeqVAVlLiYctC 81B4Ew9NVx5ZbLv2TQp1F/9Lb7WMGySLkya1mqt6peCKVKrlXf6xH+rom/MrKqeh7kJm j4YPpLIqqHTLPxIvreCh307jes7zysH+Y7pnfjMhcT29HCrussXhJn6Rm1uO6gdBuwea AFkA== X-Gm-Message-State: AFqh2krRNlRIc51VIX+zpxIyyAlKX/HTMAH0ufF7n29viXVAxycO1xNt cMF+PQVP5HB7uDn5SF/yzGNWCw== X-Google-Smtp-Source: AMrXdXv9OaXxJNIRAhfHIR4g2KvU6dBFPQkIdzBlRJmJIkVkEofkLlU/f2bxUWB83A+XMWegO3X23Q== X-Received: by 2002:a05:600c:1da3:b0:3d2:1761:3742 with SMTP id p35-20020a05600c1da300b003d217613742mr35698118wms.15.1672838714666; Wed, 04 Jan 2023 05:25:14 -0800 (PST) Received: from ?IPV6:2a01:cb14:51d:5100:d311:b137:6cee:1d91? ([2a01:cb14:51d:5100:d311:b137:6cee:1d91]) by smtp.gmail.com with ESMTPSA id n20-20020a05600c4f9400b003d9b351de26sm13692051wmq.9.2023.01.04.05.25.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Jan 2023 05:25:14 -0800 (PST) Content-Type: multipart/alternative; boundary="------------8e98QqIpzOVnMoaPW4TkESoM" Message-ID: <79ea98ff-3bd7-03ff-be40-70e851c38640@migops.com> Date: Wed, 4 Jan 2023 14:25:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: fix and document CLUSTER privileges To: Nathan Bossart Cc: Andrew Dunstan , Justin Pryzby , pgsql-hackers@postgresql.org, Robert Haas References: <20221207223924.GA4182184@nathanxps13> <20221208022559.GA27893@telsasoft.com> <20221208041313.GA216874@nathanxps13> <20221208181324.GA4385@nathanxps13> <20221214173435.GA690225@nathanxps13> <20221216045700.GA804311@nathanxps13> Content-Language: fr, en-US From: Gilles Darold In-Reply-To: <20221216045700.GA804311@nathanxps13> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------8e98QqIpzOVnMoaPW4TkESoM Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Le 16/12/2022 à 05:57, Nathan Bossart a écrit : > Here is a new version of the patch. I've moved the privilege checks to a > new function, and I added a note in the docs about clustering partitioned > tables in a transaction block (it's not allowed). > Getting into review of this patch I wonder why the CLUSTER command do not react as VACUUM FULL command when there is insuffisant privileges. For example with a partitioned table (ptnowner) and two partitions (ptnowner1 and ptnowner2) with the second partition owned by another user, let' say usr2. We have the following report when executing vacuum as usr2: testdb=> VACUUM FULL ptnowner; WARNING:  permission denied to vacuum "ptnowner", skipping it WARNING:  permission denied to vacuum "ptnowner1", skipping it VACUUM Here only ptnowner2 have been vacuumed which is correct and expected. For the cluster command: testdb=> CLUSTER; CLUSTER I would have expected something like: testdb=> CLUSTER; WARNING:  permission denied to cluster "ptnowner1", skipping it CLUSTER I mean that the silent behavior is not very helpful. This is the current behavior of the CLUSTER command and current patch adds a sentence about the silent behavior in the documentation. This is good but I just want to ask if we could want to fix this behavior too or just keep things like that with the lack of noise. Best regards, -- Gilles Darold --------------8e98QqIpzOVnMoaPW4TkESoM Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Le 16/12/2022 à 05:57, Nathan Bossart a écrit :
Here is a new version of the patch.  I've moved the privilege checks to a
new function, and I added a note in the docs about clustering partitioned
tables in a transaction block (it's not allowed).


Getting into review of this patch I wonder why the CLUSTER command do not react as VACUUM FULL command when there is insuffisant privileges. For example with a partitioned table (ptnowner) and two partitions (ptnowner1 and ptnowner2) with the second partition owned by another user, let' say usr2. We have the following report when executing vacuum as usr2:

testdb=> VACUUM FULL ptnowner;
WARNING:  permission denied to vacuum "ptnowner", skipping it
WARNING:  permission denied to vacuum "ptnowner1", skipping it
VACUUM

Here only ptnowner2 have been vacuumed which is correct and expected.

For the cluster command:

testdb=> CLUSTER;
CLUSTER


I would have expected something like:

testdb=> CLUSTER;
WARNING:  permission denied to cluster "ptnowner1", skipping it
CLUSTER

I mean that the silent behavior is not very helpful.


This is the current behavior of the CLUSTER command and current patch adds a sentence about the silent behavior in the documentation. This is good but I just want to ask if we could want to fix this behavior too or just keep things like that with the lack of noise.


Best regards,

-- 
Gilles Darold
--------------8e98QqIpzOVnMoaPW4TkESoM--