Peter Geoghegan <pg@bowt.ie> writes:
> On Wed, Jul 17, 2019 at 9:57 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> It looks that way, but how would a broken non-shared index have held up
>> autovacuuming in other databases? Maybe, as this one's xmin horizon
>> got further and further behind, the launcher eventually stopped
>> considering launching workers into any other databases? That seems
>> like a bad thing; it's postponing work that will need to be done
>> eventually.
> I don't know exactly how the launcher would behave offhand, but it's
> clear that not being able to VACUUM one table in one database (because
> it has a corrupt index) ultimately risks the availability of every
> database in the cluster. Many installations receive little to no
> supervision, so it may just be a matter of time there. That is
> certainly a bad thing.
Right, you're eventually going to get to a forced shutdown if vacuum never
succeeds on one table; no question that that's bad. My concern here is
that if we have blinders on to the extent of only processing that one
table or DB, we're unnecessarily allowing bloat to occur in other tables,
and causing that missed vacuuming work to pile up so that there's more of
it to be done once the breakage is cleared. If the DBA doesn't notice the
problem until getting into a forced shutdown, that is going to extend his
outage time --- and, in a really bad worst case, maybe make the difference
between being able to recover at all and not.
regards, tom lane
