From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: Michael Paquier <michael@paquier.xyz>,
        Postgres hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: REINDEX INDEX results in a crash for an index of pg_class since
 9.6
In-reply-to: <28313.1556663080@sss.pgh.pa.us>
References: <BC406D10-146C-4495-AC5E-492CADBFA144@anarazel.de>
 <26528.1556599820@sss.pgh.pa.us>
 <20190430070552.jzqgcy4ihalx7nur@alap3.anarazel.de>
 <30579.1556639470@sss.pgh.pa.us>
 <20190430173457.pg6i6urvevse5jer@alap3.anarazel.de>
 <29546.1556647550@sss.pgh.pa.us>
 <20190430182741.s6o7mo5ebmgxxi5x@alap3.anarazel.de>
 <16277.1556649660@sss.pgh.pa.us>
 <20190430190308.kga2z5oz7vab7w22@alap3.anarazel.de>
 <17996.1556651503@sss.pgh.pa.us>
 <20190430221045.6slpi2vm2noda5jb@alap3.anarazel.de>
 <28313.1556663080@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Tue, 30 Apr 2019 18:24:40 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <28925.1556664156.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 30 Apr 2019 18:42:36 -0400
Message-ID: <28926.1556664156@sss.pgh.pa.us>
Precedence: bulk

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 o=
f 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 o=
f 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 o=
f 8192 bytes
  REINDEX TABLE pg_database; -- mapped, shared, critical
+ ERROR:  could not read block 0 in file "base/16384/27769": read only 0 o=
f 8192 bytes
  REINDEX TABLE pg_shdescription; -- mapped, shared non-critical
+ ERROR:  could not read block 0 in file "base/16384/27769": read only 0 o=
f 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 o=
f 8192 bytes
  REINDEX INDEX pg_class_relname_nsp_index; -- mapped, non-shared, non-cri=
tical
+ ERROR:  could not read block 0 in file "base/16384/27769": read only 0 o=
f 8192 bytes
  REINDEX INDEX pg_index_indexrelid_index; -- non-mapped, non-shared, crit=
ical
+ ERROR:  could not read block 0 in file "base/16384/27769": read only 0 o=
f 8192 bytes
  REINDEX INDEX pg_index_indrelid_index; -- non-mapped, non-shared, non-cr=
itical
+ ERROR:  could not read block 0 in file "base/16384/27769": read only 0 o=
f 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 o=
f 8192 bytes
  REINDEX INDEX pg_shdescription_o_c_index; -- mapped, shared, non-critica=
l
+ ERROR:  could not read block 0 in file "base/16384/27769": read only 0 o=
f 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