Skip site navigation (1) Skip section navigation (2)

Re: max_connections, solaris semaphores and initdb

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: (view raw, whole thread or download thread mbox)
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

> 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

			regards, tom lane

In response to


pgsql-novice by date

Next:From: Isaac VetterDate: 2008-01-11 20:51:52
Subject: Re: max_connections, solaris semaphores and initdb
Previous:From: Isaac VetterDate: 2008-01-11 19:17:41
Subject: Re: max_connections, solaris semaphores and initdb

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group