Re: [HACKERS] Logical replication launcher's bgworker enabled bydefault, and max_logical_replication_workers - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: [HACKERS] Logical replication launcher's bgworker enabled bydefault, and max_logical_replication_workers
Date
Msg-id CAMsr+YGtvO0SAAeMhhGG8kqPxADjko7y2ihgW+2jCxVEicAD4Q@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Logical replication launcher's bgworker enabled bydefault, and max_logical_replication_workers  (Jaime Casanova <jaime.casanova@2ndquadrant.com>)
List 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 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



pgsql-hackers by date:

Previous
From: Jaime Casanova
Date:
Subject: Re: [HACKERS] Logical replication launcher's bgworker enabled bydefault, and max_logical_replication_workers
Next
From: Amit Langote
Date:
Subject: Re: [HACKERS] Valgrind-detected bug in partitioning code