On Wed, Feb 7, 2018 at 11:42 PM, tushar <tushar.ahuja@enterprisedb.com> wrote:
> I am getting ERROR: could not map dynamic shared memory segment in the log
> file
>
> - Please refer this scenario-
>
> in V11/V10 latest sources
>
> set parallel_setup_cost=0;
> set parallel_tuple_cost=0;
> set max_parallel_workers_per_gather=4;
> create table r(n int);
> insert into r values (generate_series(1,1000000));
> insert into r values (generate_series(1000000,2000000));
> analyze r;
>
> postgres=# select * from r where n < (select n from r where n<=10000 limit
> 6644);
> ERROR: more than one row returned by a subquery used as an expression
>
> in the log file -
>
> 2018-02-07 10:28:27.615 GMT [20569] ERROR: more than one row returned by a
> subquery used as an expression
> 2018-02-07 10:28:27.615 GMT [20569] STATEMENT: select * from r where n <
> (select n from r where n<=10000 limit 6644);
> 2018-02-07 10:28:27.616 GMT [20586] ERROR: could not map dynamic shared
> memory segment
> 2018-02-07 10:28:27.616 GMT [20587] ERROR: could not map dynamic shared
> memory segment
> 2018-02-07 10:28:27.617 GMT [20559] LOG: background worker "parallel
> worker" (PID 20586) exited with exit code 1
> 2018-02-07 10:28:27.617 GMT [20559] LOG: background worker "parallel
> worker" (PID 20587) exited with exit code 1
>
> Is this something already reported ?
I think this is expected. The leader process errors out and detaches
from the reference-counted DSM segment before the worker processes
manage to start up, and when they try to attach they can't because the
DSM segment is gone. This happens with anything that errors out very
quickly in the leader, like SELECT COUNT(r.n/0) FROM r using your
example table.
--
Thomas Munro
http://www.enterprisedb.com