Re: intermittent failures in Cygwin from select_parallel tests

On Thu, Jun 15, 2017 at 7:42 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, Jun 15, 2017 at 10:05 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Well, as Amit points out, there are entirely legitimate ways for that
>>> to happen. If the leader finishes the whole query itself before the
>>> worker reaches the dsm_attach() call, it will call dsm_detach(),
>>> destroying the segment, and the worker will hit this ERROR. That
>>> shouldn't happen very often in the real world, because we ought not to
>>> select a parallel plan in the first place unless the query is going to
>>> take a while to run, but the select_parallel test quite deliberately
>>> disarms all of the guards that would tend to discourage such plans.
>>
>> 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?
>

Yes, I think it is for next query. If you refer the log below from lorikeet:

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
2017-06-13 16:45:02.652 EDT [59404dec.2d9c:7] DETAIL: Failed process
was running: select stringu1::int2 from tenk1 where unique1 = 1;
2017-06-13 16:45:02.652 EDT [59404dec.2d9c:8] LOG: terminating any
other active server processes

Error "could not map dynamic shared memory segment" is due to query
"EXPLAIN .. SELECT * FROM tenk1" and Assertion failure is due to
another statement "select stringu1::int2 from tenk1 where unique1 =
1;".

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com