From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | "Bossart, Nathan" <bossartn(at)amazon(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: [Proposal] Allow users to specify multiple tables in VACUUM commands |
Date: | 2017-09-21 00:08:00 |
Message-ID: | 9200.1505952480@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
> On Thu, Sep 21, 2017 at 8:18 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> "Bossart, Nathan" <bossartn(at)amazon(dot)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.
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-09-21 00:14:45 | Re: compress method for spgist - 2 |
Previous Message | Tom Lane | 2017-09-20 23:54:54 | Re: Windows warnings from VS 2017 |