Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1st6qt-00DdHo-6n for pgsql-bugs@arkaria.postgresql.org; Tue, 24 Sep 2024 14:49:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1st6qs-0095VZ-IC for pgsql-bugs@arkaria.postgresql.org; Tue, 24 Sep 2024 14:49:18 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1st6qs-0095QX-9P for pgsql-bugs@lists.postgresql.org; Tue, 24 Sep 2024 14:49:18 +0000 Received: from oss.nttdata.com ([49.212.34.109]) by makus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1st6qp-000pP8-Je for pgsql-bugs@lists.postgresql.org; Tue, 24 Sep 2024 14:49:17 +0000 Received: from [192.168.11.3] (p4060217-ipxg13601funabasi.chiba.ocn.ne.jp [153.216.201.217]) by oss.nttdata.com (Postfix) with ESMTPSA id F23596063B; Tue, 24 Sep 2024 23:49:12 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at oss.nttdata.com Message-ID: Date: Tue, 24 Sep 2024 23:49:12 +0900 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: vacuumdb: permission denied for schema "pg_temp_7" Content-Language: en-US To: Nathan Bossart Cc: Michael Paquier , Christophe Pettus , vaibhave postgres , Tom Lane , Noah Misch , pgsql-bugs@lists.postgresql.org, vsekar@microsoft.com References: <20240920215030.8d.nmisch@google.com> <2603142.1726873660@sss.pgh.pa.us> <5f37ee56-14fb-44fe-9150-9eb97e10538b@oss.nttdata.com> <2649165.1726898595@sss.pgh.pa.us> <00d98a9f-bec1-4cd0-b59e-1043ae04c8bc@oss.nttdata.com> From: Fujii Masao In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2024/09/24 23:26, Nathan Bossart wrote: > Yeah, this is what I mentioned upthread [0]. If the user doesn't specify > anything in --table or --schema, then it's probably fine to silently skip > objects for which they lack privileges. But if they do explicitly specify > a table or schema that they cannot vacuum, then IMHO it'd be better to > fail. This could be debatable. To be honest, if I run something like vacuumdb mydb, *I* expect all eligible tables in that database to be vacuumed. If I forget to grant the necessary privileges to the role, I’d prefer to see errors from vacuumdb so I can fix the permissions. If we decide to skip tables without enough privilege, I’d prefer adding an option like --skip-unprivileged-tables rather than changing the default behavior. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION