Re: [COMMITTERS] pgsql: Add max_parallel_workers GUC. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [COMMITTERS] pgsql: Add max_parallel_workers GUC.
Date
Msg-id 20338.1480712866@sss.pgh.pa.us
Whole thread Raw
Responses Re: [COMMITTERS] pgsql: Add max_parallel_workers GUC.  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <rhaas@postgresql.org> writes:
> Add max_parallel_workers GUC.
> Increase the default value of the existing max_worker_processes GUC
> from 8 to 16, and add a new max_parallel_workers GUC with a maximum
> of 8.

This broke buildfarm members coypu and sidewinder.  It appears the reason
is that those machines can only get up to 30 server processes, cf this
pre-failure initdb trace:

http://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=coypu&dt=2016-12-02%2006%3A30%3A49&stg=initdb-C

creating directory data-C ... ok
creating subdirectories ... ok
selecting default max_connections ... 30
selecting default shared_buffers ... 128MB
selecting dynamic shared memory implementation ... sysv
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok

So you've reduced their available number of regular backends to less than
20, which is why their tests are now dotted with

! psql: FATAL:  sorry, too many clients already

There may well be other machines with similar issues; we won't know until
today's other breakage clears.

We could ask the owners of these machines to reduce the test parallelism
via the MAX_CONNECTIONS makefile variable, but I wonder whether this
increase was well thought out in the first place.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: HaveNFreeProcs() iterates through entire freeProcs list
Next
From: Robert Haas
Date:
Subject: Re: Performance improvement for joins where outer side is unique