Re: bug fix and documentation improvement about vacuumdb - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: bug fix and documentation improvement about vacuumdb
Date
Msg-id 20230914145757.GA1552775@nathanxps13
Whole thread Raw
In response to Re: bug fix and documentation improvement about vacuumdb  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: bug fix and documentation improvement about vacuumdb
List pgsql-hackers
On Thu, Sep 14, 2023 at 02:06:51PM +0200, Daniel Gustafsson wrote:
>> On 14 Sep 2023, at 13:21, Kuwamura Masaki <kuwamura@db.is.i.nagoya-u.ac.jp> wrote:
> 
>> PATTERN should be changed to SCHEMA because -n and -N options don't support 
>> pattern matching for schema names. The attached patch 0001 fixes this.
> 
> True, there is no pattern matching performed.  I wonder if it's worth lifting
> the pattern matching from pg_dump into common code such that tools like this
> can use it?

I agree that this should be changed to SCHEMA.  It might be tough to add
pattern matching with the current catalog query, and I don't know whether
there is demand for such a feature, but I wouldn't discourage someone from
trying.

>> Second, when we use multiple -N options, vacuumdb runs incorrectly as shown below.
>> ...
> 
>> Even specified by -N, s1.t and s2.t are vacuumed, and also the others are vacuumed 
>> twice. The attached patch 0002 fixes this.
> 
> 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...

>> 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.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

Attachment

pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: ALTER COLUMN ... SET EXPRESSION to alter stored generated column's expression
Next
From: jacktby jacktby
Date:
Subject: Buffer ReadMe Confuse