On Mon, Apr 06, 2020 at 08:42:13PM -0400, Tom Lane wrote:
>Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
>> It doesn't seem to be particularly platform-specific, but I've been
>> unable to reproduce it so far. It seems on older gcc versions, though.
>
>It's looking kind of like an uninitialized-memory problem. Note
>the latest from spurfowl,
>
>https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=spurfowl&dt=2020-04-07%2000%3A15%3A05
>
>which got through "make check" and then failed during pg_upgrade's
>repetition of the test. Similarly on rhinoceros. So there's definitely
>instability there even on one machine.
>
>Perhaps something to do with unexpected cache flushes??
>
I don't know, I've tried running the tests on a number of machines,
similar to those failing. Rapsberry Pi, Fedora 31, ... and it worked
everywhere while the failures seem consistent.
I've been able to reproduce these failures (same symptoms) by making
sure the worker (implied by force_parallel_mode=regress) won't start.
set max_parallel_workers = 0;
set force_parallel_mode = regress;
triggers exactly those failures for me (at least during make check, I
haven't tried pg_upgrade tests etc.).
So my theory is that we fail to start parallel workers on those
machines. It's not clear to me why would it be limited to some machines
and why would it be correlated to the incremental sort? I don't think
those machines have lower number of parallel workers, no?
But maybe incremental sort allowed using more parallel queries for more
queries, and we simply run out of parallel workers that way?
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
