Обсуждение: 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
On Sat, Oct 12, 2024 at 07:01:31AM +0200, Laurenz Albe wrote: > 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. I don't think our current setup is sustainable so I think it does need to be cleaned up. Also, physical/logical replication slots also needs help, I think. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com When a patient asks the doctor, "Am I going to die?", he means "Am I going to die soon?"
On Wed, Feb 19, 2025 at 10:07 PM Bruce Momjian <bruce@momjian.us> wrote:
On Sat, Oct 12, 2024 at 07:01:31AM +0200, Laurenz Albe wrote:
> 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.
The attached patch expands on Paul's original patch, further consolidating around the terms "streaming physical replication" and "streaming logical replication" in places where it makes sense. I would note that there are places where "streaming replication" makes sense (when it applies to both types) and potentially when "physical replication" might make sense when we could be talking about either streaming or wal shipping, so I don't think we can completely eliminate that, but hopefully this improves what we have.
I don't think our current setup is sustainable so I think it does need
to be cleaned up. Also, physical/logical replication slots also needs
help, I think.
I took a look through some of the replication slot stuff and ISTM that it basically gets the streaming logical/physical replication distinctions correct, and I *think*
it gets the slot distinctions correct as well, but to the degree there might be some issue there, I think it could be addressed separately.
Robert Treat
Вложения
On Wed, Feb 19, 2025 at 11:15 PM Robert Treat <rob@xzilla.net> wrote: > On Wed, Feb 19, 2025 at 10:07 PM Bruce Momjian <bruce@momjian.us> wrote: >> On Sat, Oct 12, 2024 at 07:01:31AM +0200, Laurenz Albe wrote: >> > 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. >> > > The attached patch expands on Paul's original patch, further consolidating around the terms "streaming physical replication"and "streaming logical replication" in places where it makes sense. I would note that there are places where"streaming replication" makes sense (when it applies to both types) and potentially when "physical replication" mightmake sense when we could be talking about either streaming or wal shipping, so I don't think we can completely eliminatethat, but hopefully this improves what we have. > >> >> I don't think our current setup is sustainable so I think it does need >> to be cleaned up. Also, physical/logical replication slots also needs >> help, I think. >> > > I took a look through some of the replication slot stuff and ISTM that it basically gets the streaming logical/physicalreplication distinctions correct, and I *think* > it gets the slot distinctions correct as well, but to the degree there might be some issue there, I think it could be addressedseparately. > Hey Bruce, Your recent commit on this topic [1] reminded me of the patch from earlier this year meant to address some other areas where we are blurry about using streaming vs physical vs logical replication. I think (I might possibly still be jet lagged) I have updated the previous version of that patch against HEAD, attached, and bumping it up for review. [1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a5b69e30731fb623715ecf4c8073c0f2dee41678;hp=acbc9beaaed6ee88416e1dcef5df77fd5baba0be) Robert Treat https://xzilla.net
Вложения
On Mon, Nov 24, 2025 at 11:28:22PM -0500, Robert Treat wrote: > > I took a look through some of the replication slot stuff and ISTM that it basically gets the streaming logical/physicalreplication distinctions correct, and I *think* > > it gets the slot distinctions correct as well, but to the degree there might be some issue there, I think it could beaddressed separately. > > > > Hey Bruce, > > Your recent commit on this topic [1] reminded me of the patch from > earlier this year meant to address some other areas where we are > blurry about using streaming vs physical vs logical replication. I > think (I might possibly still be jet lagged) I have updated the > previous version of that patch against HEAD, attached, and bumping it > up for review. Funny you found this patch, and I was thinking about it recently also because of the fixes for physical vs logical replication. I will apply this patch after sufficient review time, thanks. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com Do not let urgent matters crowd out time for investment in the future.