Re: ERROR: too many dynamic shared memory segments
Thomas Munro <thomas.munro@enterprisedb.com>
From: Thomas Munro <thomas.munro@enterprisedb.com>
To: Jakub Glapa <jakub.glapa@gmail.com>
Cc: Forums postgresql <pgsql-general@postgresql.org>
Date: 2017-12-07T21:30:47Z
Lists: pgsql-hackers, pgsql-general
On Tue, Dec 5, 2017 at 1:18 AM, Jakub Glapa <jakub.glapa@gmail.com> wrote: > I see that the segfault is under active discussion but just wanted to ask if > increasing the max_connections to mitigate the DSM slots shortage is the way > to go? Hi Jakub, Yes. In future releases this situation will improve (maybe we'll figure out how to use one DSM segment for all the gather nodes in your query plan, and maybe it'll be moot anyway because maybe we'll be able to use a Parallel Append for queries like yours so that it uses the same set of workers over all the child plans instead of the fork()-fest you're presumably seeing). For now your only choice, if you want that plan to run, is to crank up max_connections so that the total number of concurrently executing Gather nodes is less than about 64 + 2 * max_connections. There is also a crash bug right now in the out-of-slots case as discussed, fixed in the next point release, but even with that fix in place you'll still need a high enough max_connections setting to be sure to be able to complete the query without an error. Thanks for the report! -- Thomas Munro http://www.enterprisedb.com
Commits
-
Be more wary about shm_toc_lookup failure.
- 957ff087c822 11.0 landed
- 34653bc9833d 10.2 landed
-
Fix ReinitializeParallelDSM to tolerate finding no error queues.
- dba6e75c1113 10.2 landed
- 445dbd82a319 11.0 landed
-
Teach bitmap heap scan to cope with absence of a DSA.
- ec7629dfb98a 10.2 landed
- c6755e233be1 11.0 landed
-
Don't be so trusting that shm_toc_lookup() will always succeed.
- d4663350646c 10.0 cited