On 4/10/03 8:10 pm, Tom Lane [EMAIL PROTECTED] wrote:
I said:
Hm. The parallel regression tests require at least 20. I deliberately
allowed initdb to select values as small as 10 on the theory that
installing and not being able to run the parallel regression tests is
better than not
Tom Lane writes:
Perhaps we should avoid all attempts at cuteness and just run the
initial probes for workable shared_buffers with max_connections=20,
as well as making that be the minimum max_connections value probed for.
Anyone see a better way?
Maybe just run one loop and try pairs of
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
Anyone see a better way?
Maybe just run one loop and try pairs of (shared_buffers, max_connections):
(1000, 100) (800, 50) (600, 40) (400, 30) (200, 20) (50, 10)
Hmm ... that wouldn't work real well as-is, because if max_connections
I said:
Hm. The parallel regression tests require at least 20. I deliberately
allowed initdb to select values as small as 10 on the theory that
installing and not being able to run the parallel regression tests is
better than not installing at all.
Actually, after trying to reproduce the
Tom Lane [EMAIL PROTECTED] 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
Greg Stark [EMAIL PROTECTED] writes:
Perhaps the shared_buffers should only be set to 50% of the maximum size
probed?
I think it's reasonable to expect the DBA to make any adjustments needed
for changes in environment. Partly this is because I don't see any
defensible way to do otherwise ---
Anyone see a better way?
Switch everything to mmap and pthreads and dump all this antiquated SysV IPC
and semaphore junk? *DUCK*
You are a brave soult. I salute you.
Sincerely,
Joshua D. Drake
--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC - S/JDBC
Postgresql support,
