Re: ERROR: too many dynamic shared memory segments
Jakub Glapa <jakub.glapa@gmail.com>
From: Jakub Glapa <jakub.glapa@gmail.com>
To: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Forums postgresql <pgsql-general@postgresql.org>
Date: 2017-12-08T07:59:07Z
Lists: pgsql-hackers, pgsql-general
Thank You Thomas! -- regards, Jakub Glapa On Thu, Dec 7, 2017 at 10:30 PM, Thomas Munro <thomas.munro@enterprisedb.com > wrote: > 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