Re: Posix Shared Mem patch

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Thom Brown <thom(at)linux(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Posix Shared Mem patch
Date: 2012-06-28 17:15:54
Message-ID: CA+TgmobT1jyX7v3AH9P0+eOdPsCMt+bwhbqQK7c8W0BBoGNP6w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 28, 2012 at 12:13 PM, Thom Brown <thom(at)linux(dot)com> wrote:
> On 64-bit Linux, if I allocate more shared buffers than the system is
> capable of reserving, it doesn't start.  This is expected, but there's
> no error logged anywhere (actually, nothing logged at all), and the
> postmaster.pid file is left behind after this failure.

Fixed.

However, I discovered something unpleasant. With the new code, on
MacOS X, if you set shared_buffers to say 3200GB, the server happily
starts up. Or at least the shared memory allocation goes through just
fine. The postmaster then sits there apparently forever without
emitting any log messages, which I eventually discovered was because
it's busy initializing a billion or so spinlocks.

I'm pretty sure that this machine does not have >3TB of virtual
memory, even counting swap. So that means that MacOS X has absolutely
no common sense whatsoever as far as anonymous shared memory
allocations go. Not sure exactly what to do about that. Linux is
more sensible, at least on the system I tested, and fails cleanly.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2012-06-28 17:19:46 Re: Posix Shared Mem patch
Previous Message Jeff Janes 2012-06-28 16:53:13 Re: Covering Indexes