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

2017-01-23 Thread Petr Jelinek
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 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.
> 

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


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

2017-01-22 Thread Craig Ringer
On 23 January 2017 at 13:19, Jaime Casanova
 wrote:
> On 22 January 2017 at 23: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 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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


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

2017-01-22 Thread Jaime Casanova
On 22 January 2017 at 23: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 launcher
>

This is because the downstream needs it
https://www.postgresql.org/message-id/CAMsr%2BYHH2XRUeqWT6pn_X0tFpP5ci7Fsrsn67TDXbFLeMknhBA%40mail.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


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

2017-01-22 Thread Michael Paquier
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


logirep-bgworker.patch
Description: application/download

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers