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 1srlWS-004Jbo-9c for pgsql-bugs@arkaria.postgresql.org; Fri, 20 Sep 2024 21:50:41 +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 1srlWQ-00Cri6-8r for pgsql-bugs@arkaria.postgresql.org; Fri, 20 Sep 2024 21:50:39 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1srlWP-00Crhu-NE for pgsql-bugs@lists.postgresql.org; Fri, 20 Sep 2024 21:50:39 +0000 Received: from mail-ot1-x32a.google.com ([2607:f8b0:4864:20::32a]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1srlWM-000Fj4-Bt for pgsql-bugs@lists.postgresql.org; Fri, 20 Sep 2024 21:50:38 +0000 Received: by mail-ot1-x32a.google.com with SMTP id 46e09a7af769-709346604a7so1300291a34.1 for ; Fri, 20 Sep 2024 14:50:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leadboat.com; s=google; t=1726869033; x=1727473833; darn=lists.postgresql.org; h=user-agent: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=D5O6daxvB/oJGekieiRl4WaU1wDTqTavNRE3ufOCS1Q=; b=F+TIi17Gz2HO1fwcAq59bx+a7aMko9ataufNY9c++Wte6dEkRrKCLDHOVTLhkCd9PB msgYZUuSIvLk9NsuJbgymBQ8/AIa0tEVs9ohsh6gdS3TKVxcN1koleJERcAHGzuzL2Zf fwqwhPTKBdP2TaVtZyutfxvj0vGeSezHEL56Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726869033; x=1727473833; h=user-agent: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=D5O6daxvB/oJGekieiRl4WaU1wDTqTavNRE3ufOCS1Q=; b=n/NKJE7kf+/aNbhvVeMbtadSr9rbgoKWsJ1jVWfBjNclaka/21xn7rd+7/JAe9jPDH FjiR1Y2QN7ZXhR91lPvzi5HkJDPi+oNW8EsXDOX7mK8+EmyiXhieshrgGJcW8T7Q89kM UhKX5QFJkI/aBRlGohGL/DbbruUZ1H1ss6XrGgvpOMlLBRrurWPTIeeVOUfCwfZhHsRX FqnvO7lObyqazgE5ioMwUvdk4VbPTk4AarzGYW7CSsN56mfW+NXQ4PLtb/ua189GnRvg cWWnIoMRZ+Inf0VUQbY91DtZINxocczVUbYwT9uVQNnG7GhLEEtEFiDCAgkmkFPnA+rB PIAw== X-Forwarded-Encrypted: i=1; AJvYcCWiKx02Ud3YPnEhw+fT3mE9WuNygbbzFVTEN8lfwKW1UgDN6bn6sjm7KscRaYnmB3+YtpQ4rtYSYVlS@lists.postgresql.org X-Gm-Message-State: AOJu0Yxio/2ueaQ51X/Nh/jY+mBkIHt9OtIumd4GMcK0EvO9sF0WSo+r oB2zZ6M5xGVSdmy8XHztBqqdP99MqbgV1cbYDY5jWkAO8kM1QS11EGHiMT08vQ== X-Google-Smtp-Source: AGHT+IGG/7OZqAa6bhO3vIan2y2rWY2TOdvt4TcO1YXtLkOQE4nz4aCLRW3iVlTbAlQvAntZgmq+tw== X-Received: by 2002:a05:6870:a999:b0:270:172c:32ae with SMTP id 586e51a60fabf-2803a7a4298mr3581189fac.32.1726869033674; Fri, 20 Sep 2024 14:50:33 -0700 (PDT) Received: from google.com ([2600:1702:a20:5750::48]) by smtp.gmail.com with ESMTPSA id 586e51a60fabf-27d0b55afa5sm1286603fac.41.2024.09.20.14.50.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Sep 2024 14:50:32 -0700 (PDT) Date: Fri, 20 Sep 2024 14:50:30 -0700 From: Noah Misch To: Nathan Bossart Cc: vaibhave postgres , pgsql-bugs@lists.postgresql.org, vsekar@microsoft.com Subject: Re: vacuumdb: permission denied for schema "pg_temp_7" Message-ID: <20240920215030.8d.nmisch@google.com> References: <20240920190731.37.nmisch@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.2.12 (2023-09-09) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, Sep 20, 2024 at 03:59:32PM -0500, Nathan Bossart wrote: > On Fri, Sep 20, 2024 at 12:07:31PM -0700, Noah Misch wrote: > > v12 introduced this regression. I suspect it started when commit e0c2933 "Use > > catalog query to discover tables to process in vacuumdb" switched vacuumdb > > from a simple "VACUUM;" command to per-table commands. Non-superuser vacuumdb > > must be rare indeed for this to go unnoticed long enough to leave all > > supported branches affected. > > I think the bug actually predates that commit, but it was only broken when > --jobs > 1. Commit e0c2933 just broke the --jobs == 1 case, too. Agreed. > > That helps, but we'd probably want to do something more general about vacuumdb > > and schema USAGE permission. > > Hm. I think filtering out schemas for which you lack USAGE makes sense > when neither --schema nor --table are specified, but if the user lists an > object they can't vacuum, we should probably fail. My current thinking is > that we could still filter when --exclude-schema is used, but I'm curious > what others think. That all sounds good to me. > You might also be interested in this thread about VACUUM and USAGE [0]. > [0] https://postgr.es/m/flat/56596b81-088f-4c0c-9a88-b5f27a7a62e9%40oss.nttdata.com The outcome is odd, but I'm not worried about it.