Re: buildfarm: could not read block 3 in file "base/16384/2662":read only 0 of 8192 bytes

On 8/9/18, 12:56 AM, "Peter Geoghegan" <pg@bowt.ie> wrote:

    On Wed, Aug 8, 2018 at 7:40 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
    >> 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?
    
    Typically not, but I don't think that we can rule it out right away.
    "min_parallel_table_scan_size = 0" will make it happen, and that
    happens in quite a few regression tests. Though that doesn't include
    vacuum.sql.
    
    The animals mandrill, mantid and lapwing are all
    "force_parallel_mode=regress", according to their notes. That actually
    isn't enough to force parallel CREATE INDEX, though I tend to think it
    should be. I don't see anything interesting in their "extra_config",
    but perhaps "min_parallel_table_scan_size = 0" got in some other way.
    I don't know all that much about the buildfarm client code, and it's
    late.
    
Sorry, I just noticed this.  Mantid is my animal, so I can set "min_parallel_table_scan_size = 0"
on it if that would be helpful.  (Please reply directly if so; I'm not able to keep up with pgsql-hackers
right now.)

-- todd