Обсуждение: [HACKERS] Logical replication launcher's bgworker enabled by default, and max_logical_replication_workers
Hi all, When spawning a new instance, I found the following thing, which is surprising at first sight: postgres: bgworker: logical replication launcher There is perhaps no problem to keep that enabled by default until the release 10 wraps to give it some buildfarm coverage similarly to what has been done last year for parallel query, but what is surprising me is that even if wal_level is *not* logical this gets started. I think that something like the patch attached is needed, so as ApplyLauncherRegister() is a noop if wal_level < logical. In the same range of thoughts, it is also surprising to have the default value of max_logical_replication_workers set to 4, I would have thought that for a feature that has created more than 13k of code diffs, it would be disabled by default. Thanks, -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
On 22 January 2017 at 23:37, Michael Paquier <michael.paquier@gmail.com> wrote: > Hi all, > > When spawning a new instance, I found the following thing, which is > surprising at first sight: > postgres: bgworker: logical replication launcher > This is because the downstream needs it https://www.postgresql.org/message-id/CAMsr%2BYHH2XRUeqWT6pn_X0tFpP5ci7Fsrsn67TDXbFLeMknhBA%40mail.gmail.com > In the same range of thoughts, it is also surprising to have the > default value of max_logical_replication_workers set to 4, I would > have thought that for a feature that has created more than 13k of code > diffs, it would be disabled by default. > +1, we should that to 0 before release -- Jaime Casanova www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 23 January 2017 at 13:19, Jaime Casanova <jaime.casanova@2ndquadrant.com> wrote: > On 22 January 2017 at 23:37, Michael Paquier <michael.paquier@gmail.com> wrote: >> Hi all, >> >> When spawning a new instance, I found the following thing, which is >> surprising at first sight: >> postgres: bgworker: logical replication launcher >> > > This is because the downstream needs it > https://www.postgresql.org/message-id/CAMsr%2BYHH2XRUeqWT6pn_X0tFpP5ci7Fsrsn67TDXbFLeMknhBA%40mail.gmail.com ... and the launcher is responsible for launching workers for downstreams. We could probably have the postmaster check whether any logical replication downstreams exist anywhere and avoid starting the launcher, but that means the postmaster has to start poking in the logical replication catalog tables. That seems unnecessarily risky. -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On 23/01/17 05:37, Michael Paquier wrote: > Hi all, > > When spawning a new instance, I found the following thing, which is > surprising at first sight: > postgres: bgworker: logical replication launcher > > There is perhaps no problem to keep that enabled by default until the > release 10 wraps to give it some buildfarm coverage similarly to what > has been done last year for parallel query, but what is surprising me > is that even if wal_level is *not* logical this gets started. I think > that something like the patch attached is needed, so as > ApplyLauncherRegister() is a noop if wal_level < logical. > As discussed elsewhere, there is no need for wal_level = logical downstream and launcher is only needed for downstream. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services