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:

Reply via email to