Re: [HACKERS] CONNECTION LIMIT and Parallel Query don't play welltogether
От | Peter Eisentraut |
---|---|
Тема | Re: [HACKERS] CONNECTION LIMIT and Parallel Query don't play welltogether |
Дата | |
Msg-id | d100f62a-0606-accc-693b-cdc6d16b9296@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] CONNECTION LIMIT and Parallel Query don't play well together (David Rowley <david.rowley@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] CONNECTION LIMIT and Parallel Query don't play well together
Re: [HACKERS] CONNECTION LIMIT and Parallel Query don't play welltogether |
Список | pgsql-hackers |
On 1/11/17 5:51 PM, David Rowley wrote: > Now, since background workers > don't consume anything from max_connections, then I don't really feel > that a background worker should count towards "CONNECTION LIMIT". I'd > assume any CONNECTION LIMITs that are set for a user would be > calculated based on what max_connections is set to. If we want to > limit background workers in the same manner, then perhaps we'd want to > invent something like "WORKER LIMIT N" in CREATE USER. This explanation makes sense, but it kind of upset my background sessions patch, which would previously have been limited by per-user connection settings. So I would like to have a background worker limit per user, as you allude to. Attached is a patch that implements a GUC setting max_worker_processes_per_user. Besides the uses for background sessions, but it can also be useful for parallel workers, logical replication apply workers, or things like third-party partitioning extensions. Thoughts? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
В списке pgsql-hackers по дате отправления: