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

On Thu, Sep 21, 2017 at 9:08 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Michael Paquier <michael.paquier@gmail.com> writes:
>> On Thu, Sep 21, 2017 at 8:18 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> "Bossart, Nathan" <bossartn@amazon.com> writes:
>>>> I agree that the patch might be simpler without this, but the user-visible
>>>> behavior is the reason I had included it.  In short, my goal was to avoid
>>>> errors halfway through a long-running VACUUM statement because the user
>>>> misspelled a relation/column name or the relation/column was dropped.
>
>>> I don't particularly buy that argument, because it's not the case that
>>> the preceding processing was wasted when that happens.  We've done and
>>> committed the vacuuming work for the earlier relations.
>
>> I think that the problem can be seen differently though: the next
>> relations on the list would not be processed as well. For example in
>> parallel of a manual VACUUM triggered by a cron job, say that a rogue
>> admin removes a column for a relation to be VACUUM-ed. The relations
>> processed before the relation redefined would have been vacuumed and
>> the transaction doing the vacuum committed, but the ones listed after
>> would not have been updated in this nightly VACUUM.
>
> 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.
>
> I think it'll be much easier to understand if the behavior is always (2).
> And I don't see any particular advantage to (1) anyway, especially not
> for an unattended vacuum script.

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.

> Keep in mind that there were not-entirely-unjustified complaints upthread
> about whether we needed to add any complexity here at all. I'd just as
> soon keep the added complexity to a minimum, especially when it's in
> service of behaviors that are not clearly improvements.

Yeah, I have sympathy for that argument as well. At some point during
the review I am sure that I complained about such things :)
-- 
Michael