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

> I don't know. Maybe rebuilding invalid indexes is pointless. Don't you
> think so? An invalid index can never be turned valid, so why spend
> effort in building it at all?

After a bit of testing: it isn't used by reads, but it is used by
uniqueness checks:

CREATE TABLE u (k int);
INSERT INTO u VALUES (1);
CREATE UNIQUE INDEX u_k_uq ON u(k);

SET allow_system_table_mods = on;
UPDATE pg_index SET indisvalid = false WHERE indexrelid = 'u_k_uq'::regclass;
RESET allow_system_table_mods;

INSERT INTO u VALUES (1); -- it exists, fails
INSERT INTO u VALUES (2); -- new row, succeeds, gets indexed
INSERT INTO u VALUES (2); -- it exists, fails

If we empty it, as I suggested, uniqueness checks will only work for
new records after repack, it will ignore everything preexisting.
If we leave it alone, we get completely bogus results and also
sporadic errors like:

ERROR: could not read blocks 344..344 in file "base/5/16401": read
only 0 of 8192 bytes

The leave it alone approach only works if indisready is also true,
which would be the case for my repro above, but not for some other
scenarios. I also have a repro which results in isvalid=false,
inready=true where we should rebuild the index.

I'll create a patch for that approach, but it is a bit more complex than v1.