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
Attachments:
logirep-bgworker.patchapplication/x-download; name=logirep-bgworker.patchDownload
diff --git a/src/backend/replication/logical/launcher.c b/src/backend/replication/logical/launcher.c
index b5240dcede..05a2055a33 100644
--- a/src/backend/replication/logical/launcher.c
+++ b/src/backend/replication/logical/launcher.c
@@ -477,6 +477,9 @@ ApplyLauncherRegister(void)
if (max_logical_replication_workers == 0)
return;
+ if (wal_level < WAL_LEVEL_LOGICAL)
+ return;
+
bgw.bgw_flags = BGWORKER_SHMEM_ACCESS |
BGWORKER_BACKEND_DATABASE_CONNECTION;
bgw.bgw_start_time = BgWorkerStart_RecoveryFinished;
diff --git a/src/backend/utils/misc/postgresql.conf.sample b/src/backend/utils/misc/postgresql.conf.sample
index 661b0fa9b6..ecf330406a 100644
--- a/src/backend/utils/misc/postgresql.conf.sample
+++ b/src/backend/utils/misc/postgresql.conf.sample
@@ -163,7 +163,7 @@
#max_worker_processes = 8 # (change requires restart)
#max_parallel_workers_per_gather = 2 # taken from max_worker_processes
#max_parallel_workers = 8 # total maximum number of worker_processes
-#max_logical_replication_workers = 4 # taken from max_worker_processes
+#max_logical_replication_workers = 0 # taken from max_worker_processes
#old_snapshot_threshold = -1 # 1min-60d; -1 disables; 0 is immediate
# (change requires restart)
#backend_flush_after = 0 # measured in pages, 0 disables
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
/messages/by-id/CAMsr+YHH2XRUeqWT6pn_X0tFpP5ci7Fsrsn67TDXbFLeMknhBA@mail.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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 launcherThis is because the downstream needs it
/messages/by-id/CAMsr+YHH2XRUeqWT6pn_X0tFpP5ci7Fsrsn67TDXbFLeMknhBA@mail.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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 launcherThere 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers