ERROR: could not map dynamic shared memory segment

Started by tusharalmost 8 years ago2 messages
#1tushar
tushar.ahuja@enterprisedb.com

Hi ,

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 ?

--
regards,tushar
EnterpriseDB https://www.enterprisedb.com/
The Enterprise PostgreSQL Company

#2Thomas Munro
thomas.munro@enterprisedb.com
In reply to: tushar (#1)
Re: ERROR: could not map dynamic shared memory segment

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