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-07-19 19:24:39
Message-ID: Zpq9dx37tdUkV42U@nathan
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jul 08, 2024 at 02:29:16PM -0500, Nathan Bossart wrote:
> One thing that still bugs me is that there is no feedback sent to the user
> when autovacuum_max_workers is set higher than autovacuum_worker_slots. I
> think we should at least emit a WARNING, perhaps from the autovacuum
> launcher, i.e., once when the launcher starts and then again as needed via
> HandleAutoVacLauncherInterrupts(). Or we could fail to start in
> PostmasterMain() and then ignore later misconfigurations via a GUC check
> hook. I'm not too thrilled about adding more GUC check hooks that depend
> on the value of other GUCs, but I do like the idea of failing instead of
> silently proceeding with a different value than the user configured. Any
> thoughts?

From recent discussions, it sounds like there isn't much appetite for GUC
check hooks that depend on the values of other GUCs. Here is a new version
of the patch that adds the WARNING described above.

--
nathan

Attachment Content-Type Size
v8-0001-allow-changing-autovacuum_max_workers-without-res.patch text/plain 19.7 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David E. Wheeler 2024-07-19 19:27:49 DSO Terms Galore
Previous Message Tom Lane 2024-07-19 19:22:57 Re: Wrong results with grouping sets