Re: [GENERAL] initdb fails to allocate shared memory

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "A(dot)M(dot)" <agentm(at)themactionfaction(dot)com>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [GENERAL] initdb fails to allocate shared memory
Date: 2010-08-25 18:03:15
Message-ID: 22599.1282759395@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

"A.M." <agentm(at)themactionfaction(dot)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 segment
are to be created but the amount of available physical memory is
not 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 the
system-imposed limit on the maximum number of allowed shared
memory identifiers 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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Wojciech Strzałka 2010-08-25 18:47:10 Re: Feature proposal
Previous Message Joshua Berry 2010-08-25 17:29:06 Re: Optimizing queries that use multiple tables and many order by columns

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-08-25 18:10:23 Re: Deadlock bug
Previous Message Greg Stark 2010-08-25 17:52:10 Re: Deadlock bug