Andres Freund escribió:
> I wonder if we shouldn't make background workers use connections slots
> from max_connections similar to how superuser_reserved_connections
> work. That would mean we don't need to care about it for HS.
I remember considering this and concluding that it's messy. Suppose we
decide that the registered bgworker number would be subtracted from
max_connections: if the configuration registers as many bgworkers as
max_connections, then no client connections can take place; if there are
more bgworkers than max_connections, there's going to be errors at
startup because the last few bgworkers cannot start at all (and no
client connections will be allowed). So users would be forced to change
max_connections according to bgworkers configuration. That doesn't
sound friendly.
If, instead of subtracting bgworkers from max_connections, we were to
add the number of bgworkers to max_connections, then we're no better
than currently, because the number of bgworkers from the standby would
be different from those in the master, and we'd be back into the problem
of how to ensure that the allowed number of locks meets the restriction.
If you wanted to have more bgworkers in the master than the standby,
you'd have to advise users to increase max_connections in the standby to
fulfill the restriction.
(I currently have no proposal on how to go about solving this problem.)
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services