Re: buildfarm: could not read block 3 in file "base/16384/2662": readonly 0 of 8192 bytes
От | Peter Geoghegan |
---|---|
Тема | Re: buildfarm: could not read block 3 in file "base/16384/2662": readonly 0 of 8192 bytes |
Дата | |
Msg-id | CAH2-WznAuzsQHAObT5+neO50=_PSJYhU_npp65MHaYjdKuM=ng@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: buildfarm: could not read block 3 in file "base/16384/2662": read only 0 of 8192 bytes (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: buildfarm: could not read block 3 in file "base/16384/2662": read only 0 of 8192 bytes
Re: buildfarm: could not read block 3 in file "base/16384/2662": read only 0 of 8192 bytes Re: buildfarm: could not read block 3 in file "base/16384/2662":read only 0 of 8192 bytes |
Список | pgsql-hackers |
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. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: