On Thu, Sep 21, 2017 at 8:18 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > "Bossart, Nathan" <bossa...@amazon.com> writes: >> On 9/20/17, 2:29 PM, "Tom Lane" <t...@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
