Logical replication launcher's bgworker enabled by default, and max_logical_replication_workers
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t35901psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 28, 2026 at 08:37 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t35901_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t35901_1 && git checkout t35901_1Patchset v1 (message #1) is on t35901_1
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
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