Robert Haas <rh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
