Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6

Just when you thought it was safe to go back in the water ...

markhor just reported in with results showing that we have worse
problems than deadlock-prone tests in the back branches: 9.4
for example looks like

--
-- whole tables
REINDEX TABLE pg_class; -- mapped, non-shared, critical
+ ERROR: could not read block 0 in file "base/16384/27769": read only 0 of 8192 bytes
REINDEX TABLE pg_index; -- non-mapped, non-shared, critical
+ ERROR: could not read block 0 in file "base/16384/27769": read only 0 of 8192 bytes
REINDEX TABLE pg_operator; -- non-mapped, non-shared, critical
+ ERROR: could not read block 0 in file "base/16384/27769": read only 0 of 8192 bytes
REINDEX TABLE pg_database; -- mapped, shared, critical
+ ERROR: could not read block 0 in file "base/16384/27769": read only 0 of 8192 bytes
REINDEX TABLE pg_shdescription; -- mapped, shared non-critical
+ ERROR: could not read block 0 in file "base/16384/27769": read only 0 of 8192 bytes
-- Check that individual system indexes can be reindexed. That's a bit
-- different from the entire-table case because reindex_relation
-- treats e.g. pg_class special.
REINDEX INDEX pg_class_oid_index; -- mapped, non-shared, critical
+ ERROR: could not read block 0 in file "base/16384/27769": read only 0 of 8192 bytes
REINDEX INDEX pg_class_relname_nsp_index; -- mapped, non-shared, non-critical
+ ERROR: could not read block 0 in file "base/16384/27769": read only 0 of 8192 bytes
REINDEX INDEX pg_index_indexrelid_index; -- non-mapped, non-shared, critical
+ ERROR: could not read block 0 in file "base/16384/27769": read only 0 of 8192 bytes
REINDEX INDEX pg_index_indrelid_index; -- non-mapped, non-shared, non-critical
+ ERROR: could not read block 0 in file "base/16384/27769": read only 0 of 8192 bytes
REINDEX INDEX pg_database_oid_index; -- mapped, shared, critical
+ ERROR: could not read block 0 in file "base/16384/27769": read only 0 of 8192 bytes
REINDEX INDEX pg_shdescription_o_c_index; -- mapped, shared, non-critical
+ ERROR: could not read block 0 in file "base/16384/27769": read only 0 of 8192 bytes

No doubt this is triggered by CLOBBER_CACHE_ALWAYS.

Given this, I'm rethinking my position that we can dispense with these
test cases. Let's try putting them in a standalone test script, and
see whether that leads to failures or not. Even if it does, we'd
better keep them until we've got a fully clean bill of health from
the buildfarm.

regards, tom lane