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

From: "Bossart, Nathan" <bossartn(at)amazon(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(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-07 22:27:10
Message-ID: 370EC1B4-82EA-489E-B69E-694D3075ABA3@amazon.com
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

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.

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.

Nathan

Attachment Content-Type Size
error_on_duplicate_columns_in_analyze_v2.patch application/octet-stream 5.9 KB
vacuum_multiple_tables_v15.patch application/octet-stream 31.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2017-09-07 23:25:54 Re: Moving relation extension locks out of heavyweight lock manager
Previous Message Thomas Munro 2017-09-07 22:24:11 Re: Moving relation extension locks out of heavyweight lock manager