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
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 |
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 |