Alvaro Herrera <alvherre@commandprompt.com> writes:
> Maybe what we really ought to do is pick an internal max_connections
> value that exceeds what the max_connections GUC parameter say, adjusting
> per autovacuum configuration.
That's just cosmetic; it doesn't address the real issue, which is that
if SHMMAX or other kernel settings are too small, initdb will pick a
max_connections too low to allow the parallel regression tests to run.
The fact that the regression tests try to exercise 20 concurrent
sessions by default isn't just an accident; the thought was that if you
had a configuration too small to allow a reasonable number of concurrent
sessions, the tests ought to point it out to you. (Indeed, these days
we probably oughta try to exercise more than 20 sessions.)
But this is somewhat in conflict with our desire that buildfarm members
not fall over for random reasons --- and we've seen it happen more than
once that a test run's initdb picks a smaller-than-normal
max_connections because of transient system loads.
Perhaps we could extend pg_regress to allow "--max-connections=auto"
which would instruct it to set its connection limit to the server's
actual max_connections minus superuser reserved slots (and probably
minus a couple more to allow for backend shutdown time etc). Then the
buildfarm could use that, while we'd leave the behavior alone for normal
manual regression tests.
regards, tom lane
