On Fri, May 24, 2013 at 11:25 AM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> 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.
I agree. To put that more succinctly, if we take that approach, then
max_connections is no longer the maximum number of connections, which
is a POLA violation.
> (I currently have no proposal on how to go about solving this problem.)
If the problem were only with the size of the lock table, I'd be
somewhat inclined to propose ripping out max_locks_per_transaction and
putting in a GUC called max_locks instead. The current system seems
more confusing than helpful; when the default proves insufficient, the
recourse is usually to figure out how many objects we need to lock,
and then divide by max_connections to figure out how to set
max_locks_per_transaction, which is really backing into the problem
from the wrong end.
But I don't know what to do about the problem of needing to know how
many backends there are. I agree with Andres that it's not very
friendly to enforce a restriction that all the same worker processes
must be present on the standby.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company