1
0
mirror of https://github.com/postgres/postgres.git synced 2025-07-27 12:41:57 +03:00

Allow changing autovacuum_max_workers without restarting.

This commit introduces a new parameter named
autovacuum_worker_slots that controls how many autovacuum worker
slots to reserve during server startup.  Modifying this new
parameter's value does require a server restart, but it should
typically be set to the upper bound of what you might realistically
need to set autovacuum_max_workers.  With that new parameter in
place, autovacuum_max_workers can now be changed with a SIGHUP
(e.g., pg_ctl reload).

If autovacuum_max_workers is set higher than
autovacuum_worker_slots, a WARNING is emitted, and the server will
only start up to autovacuum_worker_slots workers at a given time.
If autovacuum_max_workers is set to a value less than the number of
currently-running autovacuum workers, the existing workers will
continue running, but no new workers will be started until the
number of running autovacuum workers drops below
autovacuum_max_workers.

Reviewed-by: Sami Imseih, Justin Pryzby, Robert Haas, Andres Freund, Yogesh Sharma
Discussion: https://postgr.es/m/20240410212344.GA1824549%40nathanxps13
This commit is contained in:
Nathan Bossart
2025-01-06 15:01:22 -06:00
parent 5e68f61192
commit c758119e5b
11 changed files with 117 additions and 31 deletions

View File

@ -8630,6 +8630,25 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv;
</listitem>
</varlistentry>
<varlistentry id="guc-autovacuum-worker-slots" xreflabel="autovacuum_worker_slots">
<term><varname>autovacuum_worker_slots</varname> (<type>integer</type>)
<indexterm>
<primary><varname>autovacuum_worker_slots</varname> configuration parameter</primary>
</indexterm>
</term>
<listitem>
<para>
Specifies the number of backend slots to reserve for autovacuum worker
processes. The default is 16. This parameter can only be set at server
start.
</para>
<para>
When changing this value, consider also adjusting
<xref linkend="guc-autovacuum-max-workers"/>.
</para>
</listitem>
</varlistentry>
<varlistentry id="guc-autovacuum-max-workers" xreflabel="autovacuum_max_workers">
<term><varname>autovacuum_max_workers</varname> (<type>integer</type>)
<indexterm>
@ -8640,7 +8659,14 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv;
<para>
Specifies the maximum number of autovacuum processes (other than the
autovacuum launcher) that may be running at any one time. The default
is three. This parameter can only be set at server start.
is three. This parameter can only be set in the
<filename>postgresql.conf</filename> file or on the server command line.
</para>
<para>
Note that a setting for this value which is higher than
<xref linkend="guc-autovacuum-worker-slots"/> will have no effect,
since autovacuum workers are taken from the pool of slots established
by that setting.
</para>
</listitem>
</varlistentry>

View File

@ -839,7 +839,7 @@ psql: error: connection to server on socket "/tmp/.s.PGSQL.5432" failed: No such
When using System V semaphores,
<productname>PostgreSQL</productname> uses one semaphore per allowed connection
(<xref linkend="guc-max-connections"/>), allowed autovacuum worker process
(<xref linkend="guc-autovacuum-max-workers"/>), allowed WAL sender process
(<xref linkend="guc-autovacuum-worker-slots"/>), allowed WAL sender process
(<xref linkend="guc-max-wal-senders"/>), allowed background
process (<xref linkend="guc-max-worker-processes"/>), etc., in sets of 19.
The runtime-computed parameter <xref linkend="guc-num-os-semaphores"/>
@ -892,7 +892,7 @@ $ <userinput>postgres -D $PGDATA -C num_os_semaphores</userinput>
When using POSIX semaphores, the number of semaphores needed is the
same as for System V, that is one semaphore per allowed connection
(<xref linkend="guc-max-connections"/>), allowed autovacuum worker process
(<xref linkend="guc-autovacuum-max-workers"/>), allowed WAL sender process
(<xref linkend="guc-autovacuum-worker-slots"/>), allowed WAL sender process
(<xref linkend="guc-max-wal-senders"/>), allowed background
process (<xref linkend="guc-max-worker-processes"/>), etc.
On the platforms where this option is preferred, there is no specific