Horton

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

Michael Paquier <michael.paquier@gmail.com>

View thread View on postgr.es
From: Michael Paquier <michael.paquier@gmail.com>
To: "Bossart, Nathan" <bossartn@amazon.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Masahiko Sawada <sawada.mshk@gmail.com>, "David G. Johnston" <david.g.johnston@gmail.com>, Robert Haas <robertmhaas@gmail.com>
Date: 2017-09-28T05:20:34Z
Lists: pgsql-hackers 
On Thu, Sep 28, 2017 at 1:20 AM, Bossart, Nathan <bossartn@amazon.com> wrote:
> On 9/26/17, 1:38 PM, "Bossart, Nathan" <bossartn@amazon.com> wrote:
>> On 9/25/17, 12:42 AM, "Michael Paquier" <michael.paquier@gmail.com> wrote:
>>> +       if (!IsAutoVacuumWorkerProcess())
>>> +           ereport(WARNING,
>>> +                 (errmsg("skipping \"%s\" --- relation no longer exists",
>>> +                         relation->relname)));
>>> I like the use of WARNING here, but we could use as well a LOG to be
>>> consistent when a lock obtention is skipped.
>>
>> It looks like the LOG statement is only emitted for autovacuum, so maybe
>> we should keep this at WARNING for consistency with the permission checks
>> below it.
>
> I've left this as-is for now.  I considered emitting this statement as a
> LOG for autovacuum, but I'm not sure there is terribly much value in
> having autovacuum explain that it is skipping a relation because it was
> concurrently dropped.  Perhaps this is something we should emit at a
> DEBUG level.  What do you think?

DEBUG would be fine as well for me. Now that your patch provides a
RangeVar consistently for all code paths, the message could show up
unconditionally.
-- 
Michael

Commits

  1. Allow multiple tables to be specified in one VACUUM or ANALYZE command.

  2. Give a better error for duplicate entries in VACUUM/ANALYZE column list.

  3. Reject ANALYZE commands during VACUUM FULL or another ANALYZE.