Re: max_connections/shared_buffers (was Re: Beta4 Tag'd and Bundled ...) - Mailing list pgsql-hackers

From Greg Stark
Subject Re: max_connections/shared_buffers (was Re: Beta4 Tag'd and Bundled ...)
Date
Msg-id 87r81semmu.fsf@stark.dyndns.tv
Whole thread Raw
In response to max_connections/shared_buffers (was Re: Beta4 Tag'd and Bundled ...)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: max_connections/shared_buffers (was Re: Beta4 Tag'd and Bundled ...)  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: max_connections/shared_buffers (was Re: Beta4 Tag'd  ("Joshua D. Drake" <jd@commandprompt.com>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:

> (BTW, on my OS X machine, with out-of-the-box configuration, initdb
> selects shared_buffers 400 and max_connections 20.  I'm guessing that
> you had either a nondefault shared memory limit, or some other process
> using shared memory.)

This points out another issue with this approach of probing for the maximum
shared memory. There might be another program using shared memory when the
probe is done -- or worse when the database is started but *not* when the
probe is run.

Perhaps the shared_buffers should only be set to 50% of the maximum size
probed? That would a) give postgres a decent chance of starting even if some
other program uses some amount of the shared memory between initdb and
database starting. and b) leave enough memory for a reasonable
max_connections?

> Anyone see a better way?

Switch everything to mmap and pthreads and dump all this antiquated SysV IPC
and semaphore junk? *DUCK*

-- 
greg



pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: [PERFORM] COUNT(*) again (was Re: Index/Function
Next
From: Tom Lane
Date:
Subject: Re: [PERFORM] COUNT(*) again (was Re: Index/Function organized table layout)