Thread: [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