Re: REPACK (CONCURRENTLY) doesn't handle invalid indexes

> I think Alvaro's point about whether invalid indexes should be rebuilt
> in the first place is worth considering further. In fact, I wonder
> whether REPACK should accept a relation containing an invalid index at
> all.

Not rebuilding it / emptying it isn't really an option, as I showed an
example in my earlier emails, not rebuilding it results in bogus
checks and statements failing with file read errors, if we empty it it
results in additional constraint violations.

Not allowing these commands (consistently) to work on tables with
invalid indexes is an option, but then that should be consistent
across all similar commands, and it will be a behavior change for
normal vacuum too.

Actually after I looked at this again after Nathan's email yesterday,
I realized that even v2 causes a regression (or lets call it a
behavior change at least), most likely v1 is a better solution.

Consider the following scenario:

CREATE TABLE orders (id int PRIMARY KEY, price int);
INSERT INTO orders VALUES (1, 10), (2, 0), (3, 20);
-- currently fails with division by zero
CREATE INDEX CONCURRENTLY orders_margin ON orders ((100/price));
-- removing bad data
DELETE FROM orders WHERE price = 0;
-- repairs the index
VACUUM FULL orders;

or another less visible example is REFRESH MATERIALIZED VIEW:

CREATE MATERIALIZED VIEW mv AS SELECT * FROM src;
REFRESH MATERIALIZED VIEW mv; -- let's say this is a daily/hourly cron
job or something like that
CREATE INDEX CONCURRENTLY mv_margin ON mv ((100/price)); -- fails
DELETE FROM src WHERE price = 0;
REFRESH MATERIALIZED VIEW mv; -- index now works on master/v1, remains
invalid in v2

And if I follow your suggestion consistently across all commands about
treating it as an invalid input the last command should fail in both
scenarios.

v1 seems to be a better/less risky version to me, especially for 19.