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

On 9/20/17, 7:58 PM, "Michael Paquier" <michael(dot)paquier(at)gmail(dot)com> wrote:
> On Thu, Sep 21, 2017 at 9:51 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
>>> On Thu, Sep 21, 2017 at 9:08 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>> Um ... so? With Nathan's proposed behavior, there are two cases depending
>>>> on just when the unexpected schema change happens:
>>>> 1. *None* of the work gets done.
>>>> 2. The work before the troublesome relation gets done, and the work after
>>>> doesn't.
>>
>>> You may be missing one which is closer to what autovacuum does:
>>> 3) Issue a warning for the troublesome relation, and get the work done
>>> a maximum.
>>
>> Well, we could certainly discuss whether the behavior on detecting a
>> conflict ought to be "error" or "warning and continue". But I do not buy
>> the value of "it might be one or the other depending on timing".
>
> I definitely agree with that, and I don't want this point to be a
> blocker for the proposed patch either. So if you feel that for now the
> focus should be on simplicity rather than reliability (my word may be
> incorrect here, I mean having a consistent and continuous flow), let's
> do so then. We could always change the implemented behavior later on.

Alright, here is something that I think is more like what Tom envisioned.
The duplicate column checks have been moved to do_analyze_rel(), and I am
hoping that it is more feasible to back-patch. The main path now
processes each specified relation individually, which admittedly makes the
patch a bit simpler.

Nathan