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 1qgyje-000U47-ND for pgsql-hackers@arkaria.postgresql.org; Fri, 15 Sep 2023 02:39:10 +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 1qgyjd-00CRUG-EE for pgsql-hackers@arkaria.postgresql.org; Fri, 15 Sep 2023 02:39:09 +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 1qgyjc-00CRU0-WE for pgsql-hackers@lists.postgresql.org; Fri, 15 Sep 2023 02:39:08 +0000 Received: from mail-oi1-x22f.google.com ([2607:f8b0:4864:20::22f]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qgyja-004cz1-Ai for pgsql-hackers@lists.postgresql.org; Fri, 15 Sep 2023 02:39:07 +0000 Received: by mail-oi1-x22f.google.com with SMTP id 5614622812f47-3a7ca8720a0so1038963b6e.2 for ; Thu, 14 Sep 2023 19:39:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1694745545; x=1695350345; darn=lists.postgresql.org; h=content-transfer-encoding:mime-version:user-agent:references :in-reply-to:from:subject:cc:to:message-id:date:from:to:cc:subject :date:message-id:reply-to; bh=ttHHw6xzuoD1IQYp4K0VhnKWek0Q253CSdeRxVBszLA=; b=XZQjJBPtu83IHWZyZoIDi9IQze2wxMTqCohmikkPYrkng2344UuWInCuseFdwkVM3W iQtweHX1Sj2U6BFPMvLMKC7/WzGPjCw1fd9YBwdS1LTOoFXCaRgj1HK9cu2uE5RnYBSv t82bZzzMNLdwRZkRtdVTRtZ9QFCKlBLfNit3f0Oe1OU4YFJlSGhKOFxUZTrrmyK7rJUq 4Hl7LOrB11WCamyWt6497HgZpsvmB+u6FXJbkD1LMbjrfqPRiqoIdawzzsNxRR6QgXqw 6/60cCTbKpciah/fubMHm+EtQmc8Bv+B5UtpwLab6lOp2xlNFTW4/QwsH34+B8VkS4yl 1sTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694745545; x=1695350345; h=content-transfer-encoding:mime-version:user-agent:references :in-reply-to:from:subject:cc:to:message-id:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=ttHHw6xzuoD1IQYp4K0VhnKWek0Q253CSdeRxVBszLA=; b=iUZpL1FjtqKJL40/l7EacVGwNwqGinggNdu0gTDcrlv25tBbhUGGysyWFvI3ulxkXk NDGgXKr05D+sccRFY+eYE9GDmnafNetPzRVV1ODGYaLAPUn8nagdc5ISZ2MhZUI6x5Ou UwaSmdubUDdltMNUMoq8dyliOUegPY4yL/qfUs/iumcw4dJ36IOazqGkQ7QfAhvyx2Cq SZCQdaB3Fmwy/cKjt9Ol33iZw/2NNaVDGJm4tSmsk1VXtXetG/z3ZRl2xn072t+xX/CZ GDTxdMy2g7YJl+T5bEHpwUwY+IvrbU8wAF5D6VXN1tLHjDGo9htzngrEbposMmpmZnGa BiYA== X-Gm-Message-State: AOJu0YzjVLNjfx+L/xvq0XXbbnr/p0xvqWGX/Qtm21XUU1jDVeAsAC6h JyMTGpqGmXi/9ckkM2qx62g= X-Google-Smtp-Source: AGHT+IH4dpa/sk+HwvZh4rJKdGErZ3qKGnH5s0XIGH+GYAghYPd0MNXhykFyMwLrQVFbAvDf1raMQQ== X-Received: by 2002:a05:6808:234d:b0:3ad:29a4:f560 with SMTP id ef13-20020a056808234d00b003ad29a4f560mr393042oib.34.1694745545117; Thu, 14 Sep 2023 19:39:05 -0700 (PDT) Received: from localhost (KD036014041111.ppp-bb.dion.ne.jp. [36.14.41.111]) by smtp.gmail.com with ESMTPSA id a26-20020aa780da000000b0068ff267f094sm1958108pfn.158.2023.09.14.19.39.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Sep 2023 19:39:04 -0700 (PDT) Date: Fri, 15 Sep 2023 11:39:01 +0900 (JST) Message-Id: <20230915.113901.1424588695581203565.horikyota.ntt@gmail.com> To: nathandbossart@gmail.com Cc: daniel@yesql.se, kuwamura@db.is.i.nagoya-u.ac.jp, pgsql-hackers@lists.postgresql.org Subject: Re: bug fix and documentation improvement about vacuumdb From: Kyotaro Horiguchi In-Reply-To: <20230914145757.GA1552775@nathanxps13> References: <9788CCDC-217A-48B0-A0F8-4F311F0F2022@yesql.se> <20230914145757.GA1552775@nathanxps13> User-Agent: Mew version 6.8 on Emacs 27.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk At Thu, 14 Sep 2023 07:57:57 -0700, Nathan Bossart wrote in > On Thu, Sep 14, 2023 at 02:06:51PM +0200, Daniel Gustafsson wrote: > > I can reproduce that, a single -N works but adding multiple -N's makes none of > > them excluded. The current coding does this: > > > > if (objfilter & OBJFILTER_SCHEMA_EXCLUDE) > > appendPQExpBufferStr(&catalog_query, "OPERATOR(pg_catalog.!=) "); > > > > If the join is instead made to exclude the oids in listed_objects with a left > > join and a clause on object_oid being null I can make the current query work > > without adding a second clause. I don't have strong feelings wrt if we should > > add a NOT IN () or fix this JOIN, but we shouldn't have a faulty join together > > with the fix. With your patch the existing join is left in place, let's fix that. > > Yeah, I think we can fix the JOIN as you suggest. I quickly put a patch > together to demonstrate. We should probably add some tests... It seems to work fine. However, if we're aiming for consistent spacing, the "IS NULL" (two spaces in between) might be an concern. > >> Third, for the description of the -N option, I wonder if "vacuum all tables except > >> in the specified schema(s)" might be clearer. The current one says nothing about > >> tables not in the specified schema. > > > > Maybe, but the point of vacuumdb is to analyze a database so I'm not sure who > > would expect anything else than vacuuming everything but the excluded schema > > when specifying -N. What else could "vacuumdb -N foo" be interpreted to do > > that can be confusing? > > I agree with Daniel on this one. +1. regards. -- Kyotaro Horiguchi NTT Open Source Software Center