Re: max_connections/shared_buffers (was Re: Beta4 Tag'd and Bundled ...)

From: Greg Stark <gsstark(at)mit(dot)edu>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: max_connections/shared_buffers (was Re: Beta4 Tag'd and Bundled ...)
Date: 2003-10-04 21:08:57
Message-ID: 87r81semmu.fsf@stark.dyndns.tv
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message James Rogers 2003-10-04 21:15:12 Uses for Index/Function organizing
Previous Message Hannu Krosing 2003-10-04 20:59:00 Re: COUNT(*) again (was Re: [HACKERS] Index/Function