On Tue, Mar 21, 2006 at 09:59:40AM -0500, Tom Lane wrote: > Andrew Dunstan <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
