Re: Rename max_parallel_degree? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Rename max_parallel_degree?
Date
Msg-id CA+TgmoZnvCbe6L4OHd2BFPGm711=9LCn+Uo3-BXOKKr+rLMU_A@mail.gmail.com
Whole thread Raw
In response to Re: Rename max_parallel_degree?  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: Rename max_parallel_degree?
List pgsql-hackers
On Fri, Sep 23, 2016 at 8:54 AM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> On 9/20/16 4:07 PM, Robert Haas wrote:
>> No, I'm assuming that the classes would be built-in.  A string tag
>> seems like over-engineering to me, particularly because the postmaster
>> needs to switch on the tag, and we need to be very careful about the
>> degree to which the postmaster trusts the contents of shared memory.
>
> I'm hoping that we can come up with something that extensions can
> participate in, without the core having to know ahead of time what those
> extensions are or how they would be categorized.
>
> My vision is something like
>
> max_processes = 512  # requires restart
>
> process_allowances = 'connection:300 superuser:10 autovacuum:10
> parallel:30 replication:10 someextension:20 someotherextension:20'
> # does not require restart

I don't think it's going to be very practical to allow extensions to
participate in the mechanism because there have to be a finite number
of slots that is known at the time we create the main shared memory
segment.

Also, it's really important that we don't add lots more surface area
for the postmaster to crash and burn.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: PATCH: Exclude additional directories in pg_basebackup
Next
From: Robert Haas
Date:
Subject: Re: Hash Indexes