From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [Pgbuildfarm-members] guppie: 64MB RAM too small? |
Date: | 2006-03-21 14:59:40 |
Message-ID: | 16787.1142953180@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | buildfarm-members pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2006-03-21 15:57:31 | Re: [Pgbuildfarm-members] guppie: 64MB RAM too small? |
Previous Message | Tom Lane | 2006-03-21 14:48:40 | Re: [Pgbuildfarm-members] guppie: 64MB RAM too small? |
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Jonsson | 2006-03-21 15:09:09 | Problems with CREATE AGGREGATE and user defined state type. |
Previous Message | Tom Lane | 2006-03-21 14:48:40 | Re: [Pgbuildfarm-members] guppie: 64MB RAM too small? |