Re: buildfarm: could not read block 3 in file "base/16384/2662": read only 0 of 8192 bytes
Todd A. Cook <todda.cook@synopsys.com>
From: "Todd A. Cook" <ToddA.Cook@synopsys.com>
To: Peter Geoghegan <pg@bowt.ie>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-08-14T21:07:28Z
Lists: pgsql-hackers
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
Commits
-
Limit depth of forced recursion for CLOBBER_CACHE_RECURSIVELY.
- f112d4088c29 9.3.25 landed
- 35e39610a3f8 9.4.20 landed
- cc4e99546ede 9.5.15 landed
- 2ef5c12ad5b6 9.6.11 landed
- adfc156d356a 10.6 landed
- 90fd3bfd1707 11.0 landed
- f510412df351 12.0 landed
-
Fix longstanding recursion hazard in sinval message processing.
- 395f310b04c5 9.6.11 landed
- 9e6f4fbdd0cf 10.6 landed
- 2569ca0dc8a2 11.0 landed
- f868a8143a98 12.0 landed
- bf919387ecc6 9.4.20 landed
- 95e9f928ce5e 9.3.25 landed
- 66321ae61baf 9.5.15 landed
-
Fix bugs in vacuum of shared rels, by keeping their relcache entries current.
- a54e1f158779 11.0 cited