Re: allow changing autovacuum_max_workers without restarting

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: "Imseih (AWS), Sami" <simseih(at)amazon(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: allow changing autovacuum_max_workers without restarting
Date: 2024-06-21 20:44:07
Message-ID: ZnXmF2FVugUVjSxN@nathan
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jun 18, 2024 at 07:43:36PM -0500, Nathan Bossart wrote:
> On Tue, Jun 18, 2024 at 02:33:31PM -0700, Andres Freund wrote:
>> Another one:
>>
>> Have a general cap of 64, but additionally limit it to something like
>> max(1, min(WORKER_CAP, max_connections / 4))
>>
>> so that cases like tap tests don't end up allocating vastly more worker slots
>> than actual connection slots.
>
> That's a clever idea. My only concern would be that we are tethering two
> parameters that aren't super closely related, but I'm unsure whether it
> would cause any problems in practice.

Here is an attempt at doing this. I've added 0001 [0] and 0002 [1] as
prerequisite patches, which helps simplify 0003 a bit. It probably doesn't
work correctly for EXEC_BACKEND builds yet.

I'm still not sure about this approach. At the moment, I'm leaning towards
something more like v2 [2] where the upper limit is a PGC_POSTMASTER GUC
(that we would set very low for TAP tests).

[0] https://commitfest.postgresql.org/48/4998/
[1] https://commitfest.postgresql.org/48/5059/
[2] https://postgr.es/m/20240419154322.GA3988554%40nathanxps13

--
nathan

Attachment Content-Type Size
v5-0001-add-num_os_semaphores-GUC.patch text/plain 8.0 KB
v5-0002-remove-check-hooks-for-GUCs-that-contribute-to-Ma.patch text/plain 4.9 KB
v5-0003-allow-changing-autovacuum_max_workers-without-res.patch text/plain 10.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-06-21 20:51:15 Re: What is a typical precision of gettimeofday()?
Previous Message Robert Haas 2024-06-21 20:35:44 Re: POC, WIP: OR-clause support for indexes