[HACKERS] Logical replication launcher's bgworker enabled by default, and max_logical_replication_workers - Mailing list pgsql-hackers

From Michael Paquier
Subject [HACKERS] Logical replication launcher's bgworker enabled by default, and max_logical_replication_workers
Date
Msg-id CAB7nPqSnZJADTCV9eDiNANiWcsicg8ecMhi+_4UUKLDGxrOwuQ@mail.gmail.com
Whole thread Raw
Responses Re: [HACKERS] Logical replication launcher's bgworker enabled bydefault, and max_logical_replication_workers  (Jaime Casanova <jaime.casanova@2ndquadrant.com>)
Re: [HACKERS] Logical replication launcher's bgworker enabled bydefault, and max_logical_replication_workers  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
List pgsql-hackers
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

Attachment

pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: [HACKERS] [PATCH] Fix minor race in commit_ts SLRU truncation vs lookups
Next
From: Dilip Kumar
Date:
Subject: Re: [HACKERS] Parallel bitmap heap scan