From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@bowt.ie>
cc: Andres Freund <andres@anarazel.de>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: buildfarm: could not read block 3 in file "base/16384/2662": read
 only 0 of 8192 bytes
In-reply-to: 
 <CAH2-WzmfC3WuVKCvBtS1agKs5kRu8uKnp_+VReYgD8D1XD0v5A@mail.gmail.com>
References: <12259.1532117714@sss.pgh.pa.us>
 <20180720202450.zcakbvyqksschz5e@alap3.anarazel.de>
 <20180725230736.nscpb5ad2tl64nez@alap3.anarazel.de>
 <CAH2-WzmfC3WuVKCvBtS1agKs5kRu8uKnp_+VReYgD8D1XD0v5A@mail.gmail.com>
Comments: In-reply-to Peter Geoghegan <pg@bowt.ie>
	message dated "Wed, 08 Aug 2018 18:42:56 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <27668.1533782451.1@sss.pgh.pa.us>
Date: Wed, 08 Aug 2018 22:40:51 -0400
Message-ID: <27669.1533782451@sss.pgh.pa.us>
Precedence: bulk

Peter Geoghegan <pg@bowt.ie> writes:
> On Wed, Jul 25, 2018 at 4:07 PM, Andres Freund <andres@anarazel.de> wrote:
>> I don't immediately see it being responsible, but I wonder if there's a
>> chance it actually is: Note that it happens in a parallel group that
>> includes vacuum.sql, which does a VACUUM FULL pg_class - but I still
>> don't immediately see how it could apply.

> Anyway, "VACUUM FULL pg_class" should be expected to corrupt
> pg_class_oid_index when we happen to get a parallel build, since
> pg_class is a mapped relation, and I've identified that as a problem
> for parallel CREATE INDEX [2]. If that was the ultimate cause of the
> issue, it would explain why only REL_11_STABLE and master are
> involved.

Oooh ... but pg_class wouldn't be big enough to get a parallel
index rebuild during that test, would it?

			regards, tom lane