On 09/08/16 12:16, Craig Ringer wrote:
On 9 August 2016 at 17:28, Masahiko Sawada <sawada.m...@gmail.com <mailto:sawada.m...@gmail.com>> wrote:> Sure, you can go deeper down the rabbit hole here and say that we need to > add bgworker "categories" with reserved pools of worker slots for each > category. But do we really need that? If we change these processes to bgworker, we can categorize them into two, auxiliary process(check pointer and wal sender etc) and other worker process. And max_worker_processes controls the latter. Right. I think that's probably the direction we should be going eventually. Personally I don't think such a change should block the logical replication work from proceeding with bgworkers, though. It's been delayed a long time, a lot of people want it, and I think we need to focus on meeting the core requirements not getting too sidetracked on minor points. Of course, everyone's idea of what's core and what's a minor sidetrack differs ;)
Yeah that's why I added local max GUC that just handles the logical worker limit within the max_worker_processes. I didn't want to also write generic framework for managing the max workers using tags or something as part of this, it's big enough as it is and we can always move the limit to the more generic place once we have it.
-- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, 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
