Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Subject: Re: shm
From: Scott Ribe <scott_ribe@elevated-dev.com>
In-Reply-To: <23559.1583508881@sss.pgh.pa.us>
Date: Fri, 6 Mar 2020 09:32:55 -0700
Cc: pgsql-admin <pgsql-admin@postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4D887459-FDD7-467A-892F-E9680B6A902F@elevated-dev.com>
References: <565DBAD4-E79D-4EE0-89C4-ABE33AD0C0A7@elevated-dev.com>
 <1582.1583419905@sss.pgh.pa.us>
 <7A7FD3C8-763B-4B29-A6FC-720D4DDB6EB7@elevated-dev.com>
 <23559.1583508881@sss.pgh.pa.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Precedence: bulk

> On Mar 6, 2020, at 8:34 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>=20
> 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...)