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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

"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

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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

---------------------------(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