public inbox for [email protected]
help / color / mirror / Atom feedFrom: Nathan Bossart <[email protected]>
To: Imseih (AWS), Sami <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: allow changing autovacuum_max_workers without restarting
Date: Thu, 11 Apr 2024 09:58:34 -0500
Message-ID: <20240411145834.GA1934019@nathanxps13> (raw)
In-Reply-To: <20240411144240.GD1882158@nathanxps13>
References: <20240410212344.GA1824549@nathanxps13>
<[email protected]>
<20240411144240.GD1882158@nathanxps13>
On Thu, Apr 11, 2024 at 09:42:40AM -0500, Nathan Bossart wrote:
> On Thu, Apr 11, 2024 at 02:24:18PM +0000, Imseih (AWS), Sami wrote:
>> max_worker_processes defines a pool of max # of background workers allowed.
>> parallel workers and extensions that spin up background workers all utilize from
>> this pool.
>>
>> Should autovacuum_max_workers be able to utilize from max_worker_processes also?
>>
>> This will allow autovacuum_max_workers to be dynamic while the user only has
>> to deal with an already existing GUC. We may want to increase the default value
>> for max_worker_processes as part of this.
>
> My concern with this approach is that other background workers could use up
> all the slots and prevent autovacuum workers from starting, unless of
> course we reserve autovacuum_max_workers slots for _only_ autovacuum
> workers. I'm not sure if we want to get these parameters tangled up like
> this, though...
I see that the logical replication launcher process uses this pool, but we
take special care to make sure it gets a slot:
/*
* Register the apply launcher. It's probably a good idea to call this
* before any modules had a chance to take the background worker slots.
*/
ApplyLauncherRegister();
I'm not sure there's another way to effectively reserve slots that would
work for the autovacuum workers (which need to restart to connect to
different databases), so that would need to be invented. We'd probably
also want to fail startup if autovacuum_max_workers < max_worker_processes,
which seems like it has the potential to cause problems when folks first
upgrade to v18.
Furthermore, we might have to convert autovacuum workers to background
worker processes for this to work. I've admittedly wondered about whether
we should do that eventually, anyway, but it'd expand the scope of this
work quite a bit.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
view thread (6+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: allow changing autovacuum_max_workers without restarting
In-Reply-To: <20240411145834.GA1934019@nathanxps13>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox