On Fri, May 24, 2013 at 11:25 AM, Alvaro Herrera <alvhe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
