Re: Streaming Replication vs Logical

2025-02-19 Thread Robert Treat
On Wed, Feb 19, 2025 at 10:07 PM Bruce Momjian  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
https://xzilla.net


v2-0001-Distinguish-between-streaming-replication-and-phy.patch
Description: Binary data


Re: pg_copy_logical_replication_slot doesn't copy the failover property

2025-02-19 Thread Shlok Kyal
On Thu, 20 Feb 2025 at 09:39, Nisha Moond  wrote:
>
> On Wed, Feb 19, 2025 at 12:40 PM Shlok Kyal  wrote:
> > Hi,
> >
> > The failover option is set to false by default while copying of the
> > slots as it may cause some issue during slot synchronization as per
> > discussion [1].
> >
> > I have created a patch to update the documentation for the same.
> >
>
> Thanks for the patch.
> A couple of comments regarding the sentence:
>
> +not copied and set as false by default due to
> +potential issues with the slot synchronization.
>
> 1) / and set as/ and is set to
> "set to" is more natural and clearer when assigning a specific value
> compared to "set as."
>
> 2) "due to potential issues..." wording implies that it is addressing
> existing issues. I feel it would be better to say:
> "... false by default to avoid potential issues
> with the slot synchronization."
>

Hi Nisha,

I have addressed the comments and attached the updated v2 patch.

Thanks and Regards,
Shlok Kyal


v2-0001-Improve-documentation-for-pg_copy_logical_replica.patch
Description: Binary data


Re: pg_copy_logical_replication_slot doesn't copy the failover property

2025-02-19 Thread Nisha Moond
On Wed, Feb 19, 2025 at 12:40 PM Shlok Kyal  wrote:
> Hi,
>
> The failover option is set to false by default while copying of the
> slots as it may cause some issue during slot synchronization as per
> discussion [1].
>
> I have created a patch to update the documentation for the same.
>

Thanks for the patch.
A couple of comments regarding the sentence:

+not copied and set as false by default due to
+potential issues with the slot synchronization.

1) / and set as/ and is set to
"set to" is more natural and clearer when assigning a specific value
compared to "set as."

2) "due to potential issues..." wording implies that it is addressing
existing issues. I feel it would be better to say:
"... false by default to avoid potential issues
with the slot synchronization."

--
Thanks,
Nisha