On Thu, Sep 21, 2017 at 8:18 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Bossart, Nathan" <bossartn@amazon.com> writes:
>> On 9/20/17, 2:29 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
>>> The idea of "fast failing" because some later VacuumRelation struct might
>>> contain an error seems like useless complication, both in terms of the
>>> implementation and the user-visible behavior.
>
>> 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. From this angle
this sounds like a fair concern to me. I agree that the rogue admin
should not have done that to begin with.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers