Peter Geoghegan <pg@xxxxxxx> writes: > On Wed, Jul 17, 2019 at 9:57 AM Tom Lane <tgl@xxxxxxxxxxxxx> 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
