From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Isaac Vetter <ivetter(at)math(dot)purdue(dot)edu> |
Cc: | pgsql-novice(at)postgresql(dot)org |
Subject: | Re: max_connections, solaris semaphores and initdb |
Date: | 2008-01-11 20:20:11 |
Message-ID: | 24218.1200082811@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
Isaac Vetter <ivetter(at)math(dot)purdue(dot)edu> writes:
> Yes. I've restarted. Even rebooted to have the /etc/system changes take
> effect. My concern is that there's a value somewhere that quietly sets
> an upper limit on what max_connections can be, that is determined from
> kernel settings when initdb is run.
Well, you're mistaken: if the system can't support the specified
max_connections then it will fail at postmaster start, not silently
reduce the parameter value.
It's certainly possible to fall foul of a kernel process-count
restriction at runtime, but the message would look like "fork failed",
not the one you're reporting.
I think you've messed up changing the effective setting of
max_connections somehow. Are you sure you edited the right copy of
postgresql.conf?
> 0) Is this correct? Does initdb set an unchangeable value that quietly
> limits the high end of max_connections?
The only thing that initdb does is put a value for max_connections into
the initial postgresql.conf file, which it chooses by experimenting to
see whether the postmaster will start with various settings. No hidden
magic.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Isaac Vetter | 2008-01-11 20:51:52 | Re: max_connections, solaris semaphores and initdb |
Previous Message | Isaac Vetter | 2008-01-11 19:17:41 | Re: max_connections, solaris semaphores and initdb |