Обсуждение:
Hi!
Let's see if someone can answer my question.
I know what logical replication is but I don't know what this process does on the server.
Even if you change the default setting of wal_level to minimal, the process continues to start after the server is restarted so that it takes the change in the wal_level parameter.
¿?
Thanks to all!
On 5/16/21 1:47 PM, Loles wrote: > Hi! > > Let's see if someone can answer my question. > > In a default PostgreSQL 13 installation, starting the server starts a > process called "logical replication launcher". > > I know what logical replication is but I don't know what this process does > on the server. > > Even if you change the default setting of wal_level to minimal, the > process continues to start after the server is restarted so that it takes > the change in the wal_level parameter. > > ¿? What's your question? -- Angular momentum makes the world go 'round.
Why the Server startup this background process?
Isn't a mandatory process.
And what's the logical replicación Launcher do?
El dom., 16 may. 2021 21:21, Ron <ronljohnsonjr@gmail.com> escribió:
On 5/16/21 1:47 PM, Loles wrote:
> Hi!
>
> Let's see if someone can answer my question.
>
> In a default PostgreSQL 13 installation, starting the server starts a
> process called "logical replication launcher".
>
> I know what logical replication is but I don't know what this process does
> on the server.
>
> Even if you change the default setting of wal_level to minimal, the
> process continues to start after the server is restarted so that it takes
> the change in the wal_level parameter.
>
> ¿?
What's your question?
--
Angular momentum makes the world go 'round.
On Mon, May 17, 2021 at 12:18 AM Loles <lolesft@gmail.com> wrote: > > Hi! > > Let's see if someone can answer my question. > > In a default PostgreSQL 13 installation, starting the server starts a process called "logical replication launcher". > > I know what logical replication is but I don't know what this process does on the server. > > Even if you change the default setting of wal_level to minimal, the process continues to start after the server is restartedso that it takes the change in the wal_level parameter. This process launches the worker process for each subscription for applying the logical replication changes. It does not matter what is the wal level, because wal level should be logical to create a publisher but this is used for launching the worker for the subscriber. So in short this process will scan the subscriber and launches the apply worker if there is no worker corresponding to some subscription. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
I don't understand why the server starts that process if I'm not using replication of any kind.
The server starts it with the default configuration of version 13.
The server starts it with the default configuration of version 13.
I think that it consumes resources that I do not need because, as I have commented, I will not use replication of any kind.
El lun, 17 may 2021 a las 7:41, Dilip Kumar (<dilipbalaut@gmail.com>) escribió:
On Mon, May 17, 2021 at 12:18 AM Loles <lolesft@gmail.com> wrote:
>
> Hi!
>
> Let's see if someone can answer my question.
>
> In a default PostgreSQL 13 installation, starting the server starts a process called "logical replication launcher".
>
> I know what logical replication is but I don't know what this process does on the server.
>
> Even if you change the default setting of wal_level to minimal, the process continues to start after the server is restarted so that it takes the change in the wal_level parameter.
This process launches the worker process for each subscription for
applying the logical replication changes. It does not matter what is
the wal level, because wal level should be logical to create a
publisher but this is used for launching the worker for the
subscriber. So in short this process will scan the subscriber and
launches the apply worker if there is no worker corresponding to some
subscription.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Sunday, May 16, 2021, Loles <lolesft@gmail.com> wrote:
I don't understand why the server starts that process if I'm not using replication of any kind.
The server starts it with the default configuration of version 13.I think that it consumes resources that I do not need because, as I have commented, I will not use replication of any kind.
It starts the process because at any time someone can execute a “create subscription” command. If no one does so the amount of time spent confirming the subscriptions table is empty is trivial.
So, yes, it consumes resources. A minimal amount, likely not enough to spend time figuring out how to avoid and risking a change to the basic operational mode of the subsystem.
David J.
Ok, now I know.
Thank you very much to all!!
El lun, 17 may 2021 a las 8:37, David G. Johnston (<david.g.johnston@gmail.com>) escribió:
On Sunday, May 16, 2021, Loles <lolesft@gmail.com> wrote:I don't understand why the server starts that process if I'm not using replication of any kind.
The server starts it with the default configuration of version 13.I think that it consumes resources that I do not need because, as I have commented, I will not use replication of any kind.It starts the process because at any time someone can execute a “create subscription” command. If no one does so the amount of time spent confirming the subscriptions table is empty is trivial.So, yes, it consumes resources. A minimal amount, likely not enough to spend time figuring out how to avoid and risking a change to the basic operational mode of the subsystem.David J.
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Sunday, May 16, 2021, Loles <lolesft@gmail.com> wrote:
>> I don't understand why the server starts that process if I'm not using
>> replication of any kind.
> It starts the process because at any time someone can execute a “create
> subscription” command. If no one does so the amount of time spent
> confirming the subscriptions table is empty is trivial.
It looks like it won't be started if you set
max_logical_replication_workers = 0.
regards, tom lane
On Monday, May 17, 2021, Tom Lane <tgl@sss.pgh.pa.us> wrote:
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Sunday, May 16, 2021, Loles <lolesft@gmail.com> wrote:
>> I don't understand why the server starts that process if I'm not using
>> replication of any kind.
> It starts the process because at any time someone can execute a “create
> subscription” command. If no one does so the amount of time spent
> confirming the subscriptions table is empty is trivial.
It looks like it won't be started if you set
max_logical_replication_workers = 0.
I was wondering about that. Would you mind posting a link to the code where that is checked? I actually looked though admittedly not that hard.
Thanks!
David J.
On Mon, May 17, 2021 at 7:37 PM David G. Johnston
<david.g.johnston@gmail.com> wrote:
>
> On Monday, May 17, 2021, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>
>> "David G. Johnston" <david.g.johnston@gmail.com> writes:
>> > On Sunday, May 16, 2021, Loles <lolesft@gmail.com> wrote:
>> >> I don't understand why the server starts that process if I'm not using
>> >> replication of any kind.
>>
>> > It starts the process because at any time someone can execute a “create
>> > subscription” command. If no one does so the amount of time spent
>> > confirming the subscriptions table is empty is trivial.
>>
>> It looks like it won't be started if you set
>> max_logical_replication_workers = 0.
>>
>
> I was wondering about that. Would you mind posting a link to the code where that is checked? I actually looked
thoughadmittedly not that hard.
>
/*
* ApplyLauncherRegister
* Register a background worker running the logical replication launcher.
*/
void
ApplyLauncherRegister(void)
{
BackgroundWorker bgw;
if (max_logical_replication_workers == 0)
return;
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Monday, May 17, 2021, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> It looks like it won't be started if you set
>> max_logical_replication_workers = 0.
> I was wondering about that. Would you mind posting a link to the code
> where that is checked? I actually looked though admittedly not that hard.
See ApplyLauncherRegister() in src/backend/replication/logical/launcher.c.
That's called from PostmasterMain(). It doesn't actually *launch* the
process, but it creates the background worker record that causes it to
be started a little later.
regards, tom lane
On Mon, May 17, 2021 at 7:13 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Monday, May 17, 2021, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> It looks like it won't be started if you set
>> max_logical_replication_workers = 0.
> I was wondering about that. Would you mind posting a link to the code
> where that is checked? I actually looked though admittedly not that hard.
See ApplyLauncherRegister() in src/backend/replication/logical/launcher.c.
That's called from PostmasterMain(). It doesn't actually *launch* the
process, but it creates the background worker record that causes it to
be started a little later.
Thanks (to you to Dilip).
Given this, should the configuration description for this include the "This parameter can only be set in postgresql.conf file or on the server command line." comment, as well as the fact that 0 disables the logical replication subscribing feature altogether, and precludes the background worker scheduler process from launching at startup?
max_logical_replication_workers (int)
David J.
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> Given this, should the configuration description for this include the "This
> parameter can only be set in postgresql.conf file or on the server command
> line." comment,
Hmm, yeah, it does lack the standard boilerplate for a PGC_POSTMASTER
GUC. I wonder which other GUCs are misidentified that way.
> as well as the fact that 0 disables the logical replication
> subscribing feature altogether, and precludes the background worker
> scheduler process from launching at startup?
I'd be in favor of mentioning the former, but the latter seems like
an implementation detail.
regards, tom lane
On Tue, May 18, 2021 at 6:46 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> as well as the fact that 0 disables the logical replication
> subscribing feature altogether, and precludes the background worker
> scheduler process from launching at startup?
I'd be in favor of mentioning the former, but the latter seems like
an implementation detail.
I can see that point - but for me the deciding factor is that this detail ends up showing up in the O/S process list and talking about that is desirable to me.
David J.