Re: intermittent failures in Cygwin from select_parallel tests

On Thu, Jun 15, 2017 at 10:32 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Thu, Jun 15, 2017 at 10:05 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> But we know, from the subsequent failed assertion, that the leader was
>>> still trying to launch parallel workers. So that particular theory
>>> doesn't hold water.
>
>> Is there any chance that it's already trying to launch parallel
>> workers for the *next* query?
>
> Oh! Yeah, you might be right, because the trace includes a statement
> LOG entry from the leader in between:
>
> 2017-06-13 16:44:57.179 EDT [59404ec6.2758:63] LOG: statement: EXPLAIN (analyze, timing off, summary off, costs off) SELECT * FROM tenk1;
> 2017-06-13 16:44:57.247 EDT [59404ec9.2e78:1] ERROR: could not map dynamic shared memory segment
> 2017-06-13 16:44:57.248 EDT [59404dec.2d9c:5] LOG: worker process: parallel worker for PID 10072 (PID 11896) exited with exit code 1
> 2017-06-13 16:44:57.273 EDT [59404ec6.2758:64] LOG: statement: select stringu1::int2 from tenk1 where unique1 = 1;
> TRAP: FailedAssertion("!(BackgroundWorkerData->parallel_register_count - BackgroundWorkerData->parallel_terminate_count <= 1024)", File: "/home/andrew/bf64/root/HEAD/pgsql.build/../pgsql/src/backend/postmaster/bgworker.c", Line: 974)
> 2017-06-13 16:45:02.652 EDT [59404dec.2d9c:6] LOG: server process (PID 10072) was terminated by signal 6: Aborted
>
> It's fairly hard to read this other than as telling us that the worker was
> launched for the EXPLAIN (although really? why aren't we skipping that if
> EXEC_FLAG_EXPLAIN_ONLY?), ...

Uh, because ANALYZE was used?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company