[HACKERS] Logical replication launcher's bgworker enabled by default, and max_logical_replication_workers

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема [HACKERS] Logical replication launcher's bgworker enabled by default, and max_logical_replication_workers
Дата
Msg-id CAB7nPqSnZJADTCV9eDiNANiWcsicg8ecMhi+_4UUKLDGxrOwuQ@mail.gmail.com
обсуждение исходный текст
Ответы 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>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: [HACKERS] [PATCH] Fix minor race in commit_ts SLRU truncation vs lookups
Следующее
От: Dilip Kumar
Дата:
Сообщение: Re: [HACKERS] Parallel bitmap heap scan