Re: [Proposal] Allow users to specify multiple tables in VACUUM commands

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: "Bossart, Nathan" <bossartn(at)amazon(dot)com>
Cc: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: [Proposal] Allow users to specify multiple tables in VACUUM commands
Date: 2017-09-08 06:27:14
Message-ID: CAB7nPqTwfuxMD=vNTOhFqHgih21_eXUX_ir3BMy4W05DdV0Cdg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Sep 8, 2017 at 7:27 AM, Bossart, Nathan <bossartn(at)amazon(dot)com> wrote:
> On 9/7/17, 2:33 AM, "Michael Paquier" <michael(dot)paquier(at)gmail(dot)com> wrote:
>> Using the patch checking for duplicate columns:
>> =# create table aa (a int);
>> CREATE TABLE
>> =# vacuum ANALYZE aa(z, z);
>> ERROR: 0A000: column lists cannot have duplicate entries
>> HINT: the column list specified for relation "aa" contains duplicates
>> LOCATION: check_column_lists, vacuum.c:619
>> Shouldn't the priority be given to undefined columns instead of
>> duplicates? You may want to add a test for that as well.
>
> I agree. I've fixed this and added a couple relevant tests cases in
> v2.

Thanks. This looks now correct to me. Except that:
+ ereport(ERROR,
+ (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+ errmsg("column lists cannot have duplicate entries"),
+ errhint("the column list specified for relation
\"%s\" contains duplicates",
+ relation->relation->relname)));
This should use ERRCODE_DUPLICATE_COLUMN.

> I've also attached a v15 of the main patch. In check_columns_exist(),
> there was a 'return' that should be a 'continue'. This caused us to
> skip the column existence checks for column lists defined after a table
> with no column list.

I can see that. Nicely spotted.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2017-09-08 06:35:20 Re: path toward faster partition pruning
Previous Message Amit Langote 2017-09-08 05:53:03 Re: Partition-wise join for join between (declaratively) partitioned tables