From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <rhaas(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [COMMITTERS] pgsql: Add max_parallel_workers GUC. |
Date: | 2016-12-02 22:34:59 |
Message-ID: | D7EBAA2C-2B1A-4E2F-AB7C-33E20B45E444@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On Dec 2, 2016, at 4:07 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <rhaas(at)postgresql(dot)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.
Signs point to "no". It seemed like a good idea to leave some daylight between max_parallel_workers and max_worker_processes, but evidently this wasn't the way to get there. Or else we should just give up on that thought.
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2016-12-02 22:37:13 | Re: [COMMITTERS] pgsql: Add max_parallel_workers GUC. |
Previous Message | Tom Lane | 2016-12-02 22:23:57 | pgsql: Fix broken wait-for-previous-process-to-exit loop in regression |
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2016-12-02 22:37:13 | Re: [COMMITTERS] pgsql: Add max_parallel_workers GUC. |
Previous Message | Jim Nasby | 2016-12-02 22:33:54 | Re: HaveNFreeProcs() iterates through entire freeProcs list |