From: Tom Lane <tgl@sss.pgh.pa.us>
To: Scott Ribe <scott_ribe@elevated-dev.com>
cc: pgsql-admin <pgsql-admin@postgresql.org>
Subject: Re: shm
In-reply-to: <7A7FD3C8-763B-4B29-A6FC-720D4DDB6EB7@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>
Comments: In-reply-to Scott Ribe <scott_ribe@elevated-dev.com>
	message dated "Fri, 06 Mar 2020 07:06:50 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <23558.1583508881.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 06 Mar 2020 10:34:41 -0500
Message-ID: <23559.1583508881@sss.pgh.pa.us>
Precedence: bulk

Scott Ribe <scott_ribe@elevated-dev.com> writes:
>> On Mar 5, 2020, at 7:51 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> We still allocate a small shm block as a means of counting live backend=
s
>> (since the SysV spec includes an "nattch" count but mmap'd segments do
>> not provide that info).  Should only be ~50 bytes though.

> I recreated the error so I could post it here:
> ERROR 53100 (disk_full) could not resize shared memory segment "/Postgre=
SQL.935653392" to 1048576 bytes: No space left on device=EF=BB=BF

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?

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.

			regards, tom lane