On Tue, Mar 21, 2006 at 09:59:40AM -0500, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
> > At the time it sets max_connections there is no server to test against.
> > initdb in fact never uses a standard client connection at all, and never
> > starts postmaster. To do a check on max_connections you would have to
> > start postmaster and then try to start that many client connections.
>
> max_connections *is* checked by initdb ... although only to the extent
> of verifying we can make that many semaphores.
Ok, I thought there was at least some kind of check in there. Maybe it
should try and determine how many processes the postmaster user is
allowed as well; presumably something like ulimit would show this.
> The parallel regression tests are not a particularly great reference
> point for this anyway, because for each parallel test case you have not
> only a server process, but a psql process, and in most shells a parent
> shell process for the psql, ie 3x the nominal level of parallelism,
> all running under the postgres userid. This isn't the normal usage
> scenario, so it would not be reasonable to restrict max_connections to
> 1/3 the number of user processes per userid.
Certainly; it doesn't make sense to be mucking around just for the sake
of make check.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461