Streaming Replication vs Logical
Our docs seem to contrast "streaming replication" to logical, but
these are not really opposites. Sometimes when they say "streaming"
they mean "physical".
Probably this is historical: at first physical replication was the
only kind of streaming we had.
Personally this has caused me a lot of confusion. For example,
recently when I read "Synchronous replication (see Section 26.2.8) is
only supported on replication slots used over the streaming
replication interface," I took it to mean synchronous replication only
worked for physical replication, not logical. But actually here the
contrast is between the streaming protocol and SQL commands. I think
it would help if the docs elsewhere took more care to say "physical"
not "streaming" when that is the meaning.
This patch fixes a callout note in the Logical Decoding section. It
was sort of vague before. It dates back to the original commit
documenting logical decoding, so I'm not sure of the original motive.
I think the new text is more precise and about the other use for
replication slots, and also clearly separates streaming replication
from physical-vs-logical replication. (I used the word "typically"
because you *can* have a standby with logical replication, although
elsewhere we warn it may not be as robust.)
I also tried to fix the first three paragraphs of
https://www.postgresql.org/docs/current/runtime-config-replication.html
which seem to be setting up a distinction between streaming
replication and logical. This is tricky, because (1) we are trying to
introduce how we've organized different config parameters, and some
affect both physical and logical replication (e.g.
max_replication_slots and wal_retrieve_retry_interval) (2) you can use
logical replication without streaming (e.g.
pg_logical_slot_get_changes).
While I was making edits there, I took out some language about
"built-in" and "feature", which seem like unnecessary wordiness.
I also added "physical" to a couple places in
https://www.postgresql.org/docs/current/warm-standby.html as well as a
Note callout to clarify that the whole page is really about using
physical replication. Technically you could use logical replication to
run a standby, but that seems like a separate discussion.
Yours,
--
Paul ~{:-)
p...@illuminatedcomputing.com
v1-0001-Distinguish-between-streaming-replication-and-phy.patch
Description: Binary data
Re: Streaming Replication vs Logical
On Fri, 2024-10-11 at 15:53 -0700, Paul A Jungwirth wrote: > Our docs seem to contrast "streaming replication" to logical, but > these are not really opposites. Sometimes when they say "streaming" > they mean "physical". > > Probably this is historical: at first physical replication was the > only kind of streaming we had. > > Personally this has caused me a lot of confusion. For example, > recently when I read "Synchronous replication (see Section 26.2.8) is > only supported on replication slots used over the streaming > replication interface," I took it to mean synchronous replication only > worked for physical replication, not logical. What you are saying makes a lot of sense, and improving some of this is a good thing. Our current trminology is a mess. There are some places in the documentation that speak of physical vs. logical replication, while most places use the term "streaming replication" for physical replication. I myself consequently speak of "streaming replication" vs. "logical replication", even though both stream data. The protocol section of the documentation describes the "streaming replication protocol" and the "logical streaming replication protocol". This is confusing, and I am also sometimes confused in the way you described above. I think the mess is too well established to be really cleaned up. But adding some clarity is a good thing, so +1. Yours, Laurenz Albe
Re: Streaming Replication vs Logical
On 12.10.24 00:53, Paul A Jungwirth wrote: Our docs seem to contrast "streaming replication" to logical, but these are not really opposites. Sometimes when they say "streaming" they mean "physical". Probably this is historical: at first physical replication was the only kind of streaming we had. Personally this has caused me a lot of confusion. For example, recently when I read "Synchronous replication (see Section 26.2.8) is only supported on replication slots used over the streaming replication interface," I took it to mean synchronous replication only worked for physical replication, not logical. But actually here the contrast is between the streaming protocol and SQL commands. I think it would help if the docs elsewhere took more care to say "physical" not "streaming" when that is the meaning. This patch fixes a callout note in the Logical Decoding section. It was sort of vague before. It dates back to the original commit documenting logical decoding, so I'm not sure of the original motive. I think the new text is more precise and about the other use for replication slots, and also clearly separates streaming replication from physical-vs-logical replication. (I used the word "typically" because you *can* have a standby with logical replication, although elsewhere we warn it may not be as robust.) I also tried to fix the first three paragraphs of https://www.postgresql.org/docs/current/runtime-config-replication.html which seem to be setting up a distinction between streaming replication and logical. This is tricky, because (1) we are trying to introduce how we've organized different config parameters, and some affect both physical and logical replication (e.g. max_replication_slots and wal_retrieve_retry_interval) (2) you can use logical replication without streaming (e.g. pg_logical_slot_get_changes). While I was making edits there, I took out some language about "built-in" and "feature", which seem like unnecessary wordiness. I also added "physical" to a couple places in https://www.postgresql.org/docs/current/warm-standby.html as well as a Note callout to clarify that the whole page is really about using physical replication. Technically you could use logical replication to run a standby, but that seems like a separate discussion. Yours, Adding clear definitions to the glossary would help users and authors alike. J. Purtz
