diff options
author | Robert Haas <rhaas@postgresql.org> | 2013-07-04 11:24:24 -0400 |
---|---|---|
committer | Robert Haas <rhaas@postgresql.org> | 2013-07-04 11:24:24 -0400 |
commit | 6bc8ef0b7f1f1df3998745a66e1790e27424aa0c (patch) | |
tree | 69fc9655772dc63e07c96e0c0e4777af7d2068b6 /doc/src | |
parent | 5cbe935c9d6046f5600ff2e083b4bae6ee1f4aa2 (diff) | |
download | postgresql-6bc8ef0b7f1f1df3998745a66e1790e27424aa0c.tar.gz postgresql-6bc8ef0b7f1f1df3998745a66e1790e27424aa0c.zip |
Add new GUC, max_worker_processes, limiting number of bgworkers.
In 9.3, there's no particular limit on the number of bgworkers;
instead, we just count up the number that are actually registered,
and use that to set MaxBackends. However, that approach causes
problems for Hot Standby, which needs both MaxBackends and the
size of the lock table to be the same on the standby as on the
master, yet it may not be desirable to run the same bgworkers in
both places. 9.3 handles that by failing to notice the problem,
which will probably work fine in nearly all cases anyway, but is
not theoretically sound.
A further problem with simply counting the number of registered
workers is that new workers can't be registered without a
postmaster restart. This is inconvenient for administrators,
since bouncing the postmaster causes an interruption of service.
Moreover, there are a number of applications for background
processes where, by necessity, the background process must be
started on the fly (e.g. parallel query). While this patch
doesn't actually make it possible to register new background
workers after startup time, it's a necessary prerequisite.
Patch by me. Review by Michael Paquier.
Diffstat (limited to 'doc/src')
-rw-r--r-- | doc/src/sgml/bgworker.sgml | 5 | ||||
-rw-r--r-- | doc/src/sgml/config.sgml | 19 |
2 files changed, 24 insertions, 0 deletions
diff --git a/doc/src/sgml/bgworker.sgml b/doc/src/sgml/bgworker.sgml index b0dde7564d8..f7126388af1 100644 --- a/doc/src/sgml/bgworker.sgml +++ b/doc/src/sgml/bgworker.sgml @@ -146,4 +146,9 @@ typedef struct BackgroundWorker The <filename>worker_spi</> contrib module contains a working example, which demonstrates some useful techniques. </para> + + <para> + The maximum number of registered background workers is limited by + <xref linkend="guc-max-worker-processes">. + </para> </chapter> diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 437dbb7711c..9126bc37cb5 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -1595,6 +1595,25 @@ include 'filename' </para> </listitem> </varlistentry> + + <varlistentry id="guc-max-worker-processes" xreflabel="max_worrker_processes"> + <term><varname>max_worker_processes</varname> (<type>integer</type>)</term> + <indexterm> + <primary><varname>max_worker_processes</> configuration parameter</primary> + </indexterm> + <listitem> + <para> + Sets the maximum number of background processes that the system + can support. This parameter can only be set at server start. + </para> + + <para> + When running a standby server, you must set this parameter to the + same or higher value than on the master server. Otherwise, queries + will not be allowed in the standby server. + </para> + </listitem> + </varlistentry> </variablelist> </sect2> </sect1> |