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

  1. Be more wary about shm_toc_lookup failure.

  2. Fix ReinitializeParallelDSM to tolerate finding no error queues.

  3. Teach bitmap heap scan to cope with absence of a DSA.

  4. Don't be so trusting that shm_toc_lookup() will always succeed.