Re: shm

From: Scott Ribe <scott_ribe(at)elevated-dev(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-admin <pgsql-admin(at)postgresql(dot)org>
Subject: Re: shm
Date: 2020-03-06 16:32:55
Message-ID: 4D887459-FDD7-467A-892F-E9680B6A902F@elevated-dev.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

> On Mar 6, 2020, at 8:34 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Oh, if it's trying to resize then this is dynamic shared memory, not
> the small static block. On most platforms we use POSIX shm_open() for
> that purpose, not SysV-style shm ... what have you got
> dynamic_shared_memory_type set to?

I just confirmed that it is POSIX. (I'm pretty sure we've never even considered changing the default.) So it would seem that, in this context at least, the limit applies to it. And the context is containerized, Kubernetes, where there is no option to set the container's shm limit so we just have to use the shm mount trick.

> It could be that the space limit applies to both APIs anyway, in which
> case your choices are to raise the limit or disable parallel query.

Well if it's coming from parallel query then I'm OK with the workaround. Primarily I wanted to make sure it wasn't caused by something dumb/worthless that we should just not do. (For instance, for historical reasons, we are temporarily running with max_connections way higher than is good practice...)

In response to

  • Re: shm at 2020-03-06 15:34:41 from Tom Lane

Browse pgsql-admin by date

  From Date Subject
Next Message Ashkar Dev 2020-03-07 19:29:51 duplicate key value violates unique constraint
Previous Message Tom Lane 2020-03-06 15:34:41 Re: shm