No title
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.
¿?
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ó:
Show quoted text
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 ittakes
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 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
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.
El lun, 17 may 2021 a las 7:41, Dilip Kumar (<dilipbalaut@gmail.com>)
escribió:
Show quoted text
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ó:
Show quoted text
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 though admittedly 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 thathard.
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?
https://www.postgresql.org/docs/current/runtime-config-replication.html
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.