On Thu, Sep 21, 2017 at 9:08 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Michael Paquier <michael.paqu...@gmail.com> writes: >> On Thu, Sep 21, 2017 at 8:18 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> "Bossart, Nathan" <bossa...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
