Обсуждение: Re: [Pgbuildfarm-members] guppie: 64MB RAM too small?
Adding -hackers. On Tue, Mar 21, 2006 at 02:20:09PM +0100, Christian Mair wrote: > > > No, let's start again. > > > > The user's machine ran out of resources. That can't be because inbitdb set > > max_connections too low - if anything it has probably set them too high. I > > suggested that he could possibly limit resource use by limiting the number > > of concurrent connections "make check" would use, by using the *UNRELATED* > > MAX_CONNECTIONS=n make flag. This flag is not part of buildfarm - it > > predates buildfarm in fact. It's part of the postgres build system - look in > > pg_regress.sh and the associated make file. Buildfarm has support for it as > > shown in the sample config file. > > Yes, > Neither PostgreSQL nor the buildfarm code is to blame. > The problem was OpenBSD's restrictive default limit of max 64 > user processes. I raised that on OpenBSD's side and as you can see > guppie turned green :) Ok, lets go back to my original point then: initdb should be made to check that you can actually open as many connections as it's trying to set max_connections to. If it can't, it should drop max_connections down (and possibly add a note to postgresql.conf indicating that it did so). -- 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
Jim C. Nasby wrote: >Adding -hackers. > > [removing -buildfarm :-) ] >Ok, lets go back to my original point then: initdb should be made to >check that you can actually open as many connections as it's trying to >set max_connections to. If it can't, it should drop max_connections down >(and possibly add a note to postgresql.conf indicating that it did so). > > 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. That's a lot of extra lifting to put into initdb for what is arguably at worst a rare problem. cheers andrew
"Jim C. Nasby" <jnasby@pervasive.com> writes:
> Ok, lets go back to my original point then: initdb should be made to
> check that you can actually open as many connections as it's trying to
> set max_connections to.
Apparently you are unaware that it's done that for a long time.
regards, tom lane
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.
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.
regards, tom lane
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