Re: Corrupt index stopping autovacuum system wide

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> On 2019-Jul-17, Peter Geoghegan wrote:
>> Maybe nbtree VACUUM should do something more aggressive than give up
>> when there is a "failed to re-find parent key" or similar condition.
>> Perhaps it would make more sense to make the index inactive (for some
>> value of "inactive") instead of just complaining. That might be the
>> least worst option, all things considered.

> Maybe we can mark an index as unvacuumable in some way? As far as I
> understand, all queries using that index work, as do index updates; it's
> just vacuuming that fails. If we mark the index as unvacuumable, then
> vacuum just skips it (and does not run phase 3 for that table), and
> things can proceed; the table's age can still be advanced. Obviously
> it'll result in more bloat than in normal condition, but it shouldn't
> cause the whole cluster to go down.

If an index is corrupt enough to break vacuum, I think it takes a rather
large leap of faith to believe that it's not going to cause problems for
inserts or searches. I'd go with just marking the index broken and
insisting that it be REINDEX'd before we touch it again.

Not sure how we make that happen automatically though, or if we even
should.
(a) once the transaction's failed, you can't go making catalog updates;
(b) even when you know the transaction's failed, blaming it on a
particular index seems a bit chancy;
(c) automatically disabling constraint indexes seems less than desirable.

regards, tom lane