There is no description about "Logical Replication also use or occupy max_wal_senders ",

On Wed, Aug 23, 2023, at 10:55 AM, PG Doc comments form wrote:

max_wal_senders (integer)

Specifies the maximum number of concurrent connections from standby servers
or streaming base backup clients (i.e., the maximum number of simultaneously
running WAL sender processes). The default is 10. The value 0 means
replication is disabled. Abrupt disconnection of a streaming client might
leave an orphaned connection slot behind until a timeout is reached, so this
parameter should be set slightly higher than the maximum number of expected
clients so disconnected clients can immediately reconnect. This parameter
can only be set at server start. Also, wal_level must be set to replica or
higher to allow connections from standby servers.

When running a standby server, you must set this parameter to the same or
higher value than on the primary server. Otherwise, queries will not be
allowed in the standby server.

In the above description， there is no description about "Logical Replication
also use or occupy max_wal_senders ",

According to the glossary [1]https://www.postgresql.org/docs/current/glossary.html, standby server (referred as "replica") is

Replica (server)
A database that is paired with a primary database and is maintaining a copy of
some or all of the primary database's data. The foremost reasons for doing this
are to allow for greater access to that data, and to maintain availability of
the data in the event that the primary becomes unavailable.

... and it implies both (logical and physical) replicas. The logical
replication [2]https://www.postgresql.org/docs/current/logical-replication-config.html setup also informs that you need to adjust max_wal_senders.

Maybe the "standby" terminology could be expanded to avoid confusion for users
from other technologies. If I were to suggest a modification, it would be in
the first paragraph in the "Replication" section [3]https://www.postgresql.org/docs/current/runtime-config-replication.html (something like "Primaries
can send data, while standbys are always receivers of physically or logically
replicated data") or even better rephrase the "Replica (server)" term in the
glossary [1]https://www.postgresql.org/docs/current/glossary.html.

so, I suggest the following modification:
Specifies the maximum number of concurrent connections from standby servers
or streaming base backup clients and Logical Replication (i.e., the
maximum number of simultaneously running WAL sender processes). ---please
note ,"and Logical Replication" is newly added。

The logical replication feature wasn't newly added. It was added almost 6 years
ago and version 10 (that adds it) was EOL more than 9 months ago.

[1]: https://www.postgresql.org/docs/current/glossary.html
[2]: https://www.postgresql.org/docs/current/logical-replication-config.html
[3]: https://www.postgresql.org/docs/current/runtime-config-replication.html

--
Euler Taveira
EDB https://www.enterprisedb.com/

I started digging into this and came up with a can of worms. I have
therefore updated the email subject.

Our glossary has:

https://www.postgresql.org/docs/devel/glossary.html

--> Standby (server)

See Replica (server).

--> Replica (server)

A database that is paired with a primary database and is maintaining
a copy of some or all of the primary database's data. The foremost
reasons for doing this are to allow for greater access to that data, and
to maintain availability of the data in the event that the primary
becomes unavailable.

So, both physical and logical replication can create standbys/replicas:

https://www.postgresql.org/docs/devel/logical-replication-subscription.html

A logical replication subscription can be a standby for
synchronous replication (see Section 27.2.8).

So, when we are talking about max_wal_senders, is it clear we are
talking a about physical replicas, logical replicas, and logical
subscribers that might not be using their data in a standby/replica
role? They might be using it in a replica role but not a standby role,
and if that is true, standby and replica are not synonyms, and maybe we
need to use replica in more places, or somehow clarify this.

There are other cases in our docs where we call something a standby and
mean only a physical standby/replica. Should these be clarified?

---------------------------------------------------------------------------

On Wed, Aug 23, 2023 at 03:31:04PM -0300, Euler Taveira wrote:

On Wed, Aug 23, 2023, at 10:55 AM, PG Doc comments form wrote:

max_wal_senders (integer)

Specifies the maximum number of concurrent connections from standby servers
or streaming base backup clients (i.e., the maximum number of
simultaneously
running WAL sender processes). The default is 10. The value 0 means
replication is disabled. Abrupt disconnection of a streaming client might
leave an orphaned connection slot behind until a timeout is reached, so
this
parameter should be set slightly higher than the maximum number of expected
clients so disconnected clients can immediately reconnect. This parameter
can only be set at server start. Also, wal_level must be set to replica or
higher to allow connections from standby servers.

When running a standby server, you must set this parameter to the same or
higher value than on the primary server. Otherwise, queries will not be
allowed in the standby server.

In the above description， there is no description about "Logical
Replication
also use or occupy max_wal_senders ",

According to the glossary [1], standby server (referred as "replica") is

Replica (server)
A database that is paired with a primary database and is maintaining a copy of
some or all of the primary database's data. The foremost reasons for doing this
are to allow for greater access to that data, and to maintain availability of
the data in the event that the primary becomes unavailable.

... and it implies both (logical and physical) replicas. The logical
replication [2] setup also informs that you need to adjust max_wal_senders.

Maybe the "standby" terminology could be expanded to avoid confusion for users
from other technologies. If I were to suggest a modification, it would be in
the first paragraph in the "Replication" section [3] (something like "Primaries
can send data, while standbys are always receivers of physically or logically
replicated data") or even better rephrase the "Replica (server)" term in the
glossary [1].

so, I suggest the following modification:
Specifies the maximum number of concurrent connections from standby servers
or streaming base backup clients and Logical Replication (i.e., the
maximum number of simultaneously running WAL sender processes). ---please
note ,"and Logical Replication" is newly added。

The logical replication feature wasn't newly added. It was added almost 6 years
ago and version 10 (that adds it) was EOL more than 9 months ago.

[1] https://www.postgresql.org/docs/current/glossary.html
[2] https://www.postgresql.org/docs/current/logical-replication-config.html
[3] https://www.postgresql.org/docs/current/runtime-config-replication.html

--
Euler Taveira
EDB https://www.enterprisedb.com/

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com

Only you can decide what is important to you.

On 06.09.23 03:42, Bruce Momjian wrote:

There are other cases in our docs where we call something a standby and
mean only a physical standby/replica. Should these be clarified?

When "hot standby" was added, I argued that it's not really a standby if
it's hot. The response was that this is sort of a standard industry
term, and we should read "standby" to be equivalent to "replica". Which
I think is good enough. Obviously, the term "standby" is baked into
many user-visible interfaces, so it's not clear whether there is a clean
path to improving anything here.

On Wed, Sep 6, 2023 at 09:02:02AM +0200, Peter Eisentraut wrote:

On 06.09.23 03:42, Bruce Momjian wrote:

There are other cases in our docs where we call something a standby and
mean only a physical standby/replica. Should these be clarified?

When "hot standby" was added, I argued that it's not really a standby if
it's hot. The response was that this is sort of a standard industry term,
and we should read "standby" to be equivalent to "replica". Which I think
is good enough. Obviously, the term "standby" is baked into many
user-visible interfaces, so it's not clear whether there is a clean path to
improving anything here.

If we don't want to change the standby == replica assumption, we still
need improvement.

How do we describe physical replicas in the docs?

https://www.postgresql.org/docs/devel/runtime-config-wal.html#RUNTIME-CONFIG-WAL-SETTINGS
wal_level (enum)

wal_level determines how much information is written to the WAL. The
default value is replica, which writes enough data to support WAL
archiving and replication, including running read-only queries on a
standby server.
--------------

That is clearly not a logical standby/replica.

If a server subscribes to one table via logical replication, is it a
replica/standby server?

https://www.postgresql.org/docs/devel/runtime-config-replication.html#RUNTIME-CONFIG-REPLICATION-SENDER
max_wal_senders (integer)

Specifies the maximum number of concurrent connections from standby
-------
servers or streaming base backup clients (i.e., the maximum number of
-------
simultaneously running WAL sender processes).

The email that started this thread was caused by confusion that logical
subscribers are part of the max_wal_senders allocation. While logical
replication _can_ be used for standby purposes, it has many other uses.

For physical replication, a hot standby can still be used for standby
purposes, while for logical replication, most of its uses cannot be used
for standby purposes.

My initial recommendation is that we keep "standby" for physical
replicas, hot and warm, and we use "replica" for physical and logical
replication receivers. In this case, replica == "receiver of
replication".

I am ready to prepare a patch to clarify all this once we decide what is
appropriate.

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com

Only you can decide what is important to you.