Horton
Menu

Re: allow changing autovacuum_max_workers without restarting

Sami Imseih <simseih@amazon.com>

View thread
From: "Imseih (AWS), Sami" <simseih@amazon.com>
To: Nathan Bossart <nathandbossart@gmail.com>, Justin Pryzby <pryzby@telsasoft.com>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2024-04-15T17:41:04Z
Lists: pgsql-hackers 
> Another option could be to just remove the restart-only GUC and hard-code
> the upper limit of autovacuum_max_workers to 64 or 128 or something. While
> that would simplify matters, I suspect it would be hard to choose an
> appropriate limit that won't quickly become outdated.

Hardcoded values are usually hard to deal with because they are hidden either
In code or in docs.

> When I thought about this, I considered proposing to add a new GUC for
> "autovacuum_policy_workers".

> autovacuum_max_workers would be the same as before, requiring a restart
> to change.  The policy GUC would be the soft limit, changable at runtime

I think autovacuum_max_workers should still be the GUC that controls
the number of concurrent autovacuums. This parameter is already well 
established and changing the meaning now will be confusing. 

I suspect most users will be glad it's now dynamic, but will probably 
be annoyed if it's no longer doing what it's supposed to.

Regards,

Sami

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Give up on running with NetBSD/OpenBSD's default semaphore settings.

  2. initdb: Do not report default autovacuum_worker_slots.

  3. Lower default value of autovacuum_worker_slots in initdb as needed.

  4. Allow changing autovacuum_max_workers without restarting.

  5. Reserve a PGPROC slot and semaphore for the slotsync worker process.

  6. Make archiver process an auxiliary process.

  7. Correct the formulas for System V IPC parameters SEMMNI and SEMMNS in docs.