| From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
|---|---|
| To: | Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com> |
| Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Logical replication launcher's bgworker enabled by default, and max_logical_replication_workers |
| Date: | 2017-01-23 05:42:14 |
| Message-ID: | CAMsr+YGtvO0SAAeMhhGG8kqPxADjko7y2ihgW+2jCxVEicAD4Q@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 23 January 2017 at 13:19, Jaime Casanova
<jaime(dot)casanova(at)2ndquadrant(dot)com> wrote:
> On 22 January 2017 at 23:37, Michael Paquier <michael(dot)paquier(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Langote | 2017-01-23 05:45:43 | Re: Valgrind-detected bug in partitioning code |
| Previous Message | Jaime Casanova | 2017-01-23 05:19:16 | Re: Logical replication launcher's bgworker enabled by default, and max_logical_replication_workers |