Re: buildfarm: could not read block 3 in file "base/16384/2662": readonly 0 of 8192 bytes
От | Andrew Dunstan |
---|---|
Тема | Re: buildfarm: could not read block 3 in file "base/16384/2662": readonly 0 of 8192 bytes |
Дата | |
Msg-id | 4818f319-fadf-7fa3-626e-729b3123fe0b@2ndQuadrant.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>) |
Список | pgsql-hackers |
On 08/09/2018 01:03 AM, Tom Lane wrote: > Peter Geoghegan <pg@bowt.ie> writes: >> On Wed, Aug 8, 2018 at 7:40 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> 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. > Hmmm ... maybe we should temporarily stick in an elog(LOG) showing whether > a parallel build happened or not, so that we can check the buildfarm logs > next time we see that failure? > >> I don't know all that much about the buildfarm client code, and it's >> late. > It doesn't really stick in any undocumented configuration changes, > AFAIK. Possibly Andrew would have some more insight. No, everything should be visible in the config. Hidden things are what I try to avoid. The only things the configure() adds are the prefix and pgport settings, and the cache-file. make() only adds a "-j jobs" if so configured. make_check() normally just runs "make NO_LOCALE=1 check". cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: