On 09/08/16 12:16, Craig Ringer wrote:
> On 9 August 2016 at 17:28, Masahiko Sawada <sawada.mshk@gmail.com
> <mailto:sawada.mshk@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