"A.M." <agentm@themactionfaction.com> writes:
> On Aug 25, 2010, at 12:28 PM, Tom Lane wrote:
>> However, it's odd that you got this variant of the HINT and not the one
>> that suggests increasing SHMMAX. Looking at the code, that means that
>> shmget returned ENOMEM, not EINVAL, which surprises me.
> I was already running an instance of pgsql 8.4, so that sucked up all
> the shared mem space and there was none left for 9.0b4.
Ah-hah. I now realize that we've been interpreting ENOMEM too narrowly.
The Single Unix Spec defines ENOMEM from shmget thusly:
[ENOMEM]A shared memory identifier and associated shared memory segmentare to be created but the amount of available
physicalmemory isnot sufficient to fill the request.
from which you'd assume that the only way to fix it is (a) buy more RAM
or (b) decrease the request size. Thus we only suggest (b). However,
it appears from your report that OS X is also using ENOMEM when SHMALL
is exceeded, which is not all that surprising because actually none of
the spec-defined error codes cover SHMALL exhaustion. The Linux manpage
for shmget says that ENOSPC is used when SHMALL is exhausted, which is
equally reasonable but it's *not* what we read in SUS:
[ENOSPC]A shared memory identifier is to be created but thesystem-imposed limit on the maximum number of allowed
sharedmemoryidentifiers system-wide would be exceeded.
So apparently different implementations are not very consistent about
which code they return for SHMALL exhaustion, and we should change the
wording for the ENOMEM hint to mention SHMALL as a possible cause.
regards, tom lane