Re: Logical Replication WIP
От | Petr Jelinek |
---|---|
Тема | Re: Logical Replication WIP |
Дата | |
Msg-id | ef3e50fe-59cf-5d9a-0186-b8892ca8fa48@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: Logical Replication WIP (Craig Ringer <craig@2ndquadrant.com>) |
Ответы |
Re: Logical Replication WIP
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: