On 09/08/16 12:16, Craig Ringer wrote:
On 9 August 2016 at 17:28, Masahiko Sawada <sawada.m...@gmail.com
> 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
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
Of course, everyone's idea of what's core and what's a minor sidetrack
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 (email@example.com)
To make changes to your subscription: