pgsql: doc: remove verbiage about "receiving" data from rep. slots
doc: remove verbiage about "receiving" data from rep. slots
The slots are just LSN markers, not something to receive from.
Backpatch-through: master
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/a554389fb5f96baba834c28bd4fc802fa1c8065f
Modified Files
--------------
doc/src/sgml/logical-replication.sgml | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
Hi,
On 2025-11-14 13:56:06 +0000, Bruce Momjian wrote:
doc: remove verbiage about "receiving" data from rep. slots
The slots are just LSN markers, not something to receive from.
I think this is wrong. Logical slots also preserve resources other than WAL.
Greetings,
Andres Freund
Hi,
On 2025-11-14 09:02:12 -0500, Andres Freund wrote:
On 2025-11-14 13:56:06 +0000, Bruce Momjian wrote:
doc: remove verbiage about "receiving" data from rep. slots
The slots are just LSN markers, not something to receive from.
I think this is wrong. Logical slots also preserve resources other than WAL.
I also think that the complaint about slots not being something to receive
from is simply wrong for logical slots.
Greetings,
Andres Freund
On Fri, Nov 14, 2025 at 09:05:07AM -0500, Andres Freund wrote:
Hi,
On 2025-11-14 09:02:12 -0500, Andres Freund wrote:
On 2025-11-14 13:56:06 +0000, Bruce Momjian wrote:
doc: remove verbiage about "receiving" data from rep. slots
The slots are just LSN markers, not something to receive from.
I think this is wrong. Logical slots also preserve resources other than WAL.
I also think that the complaint about slots not being something to receive
from is simply wrong for logical slots.
Uh, can you clarify since I can't find details on what they preserve.
The reason I liked the new wording is that the slot is only a small part
of the receiving path. Almost by definition, the slot is specified as
_part_ of the connection parameter --- it is not the connection
parameter.
Can you think of better wording that would be clearer than what we had?
--
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.
Hi,
On 2025-11-14 09:12:33 -0500, Bruce Momjian wrote:
On Fri, Nov 14, 2025 at 09:05:07AM -0500, Andres Freund wrote:
Hi,
On 2025-11-14 09:02:12 -0500, Andres Freund wrote:
On 2025-11-14 13:56:06 +0000, Bruce Momjian wrote:
doc: remove verbiage about "receiving" data from rep. slots
The slots are just LSN markers, not something to receive from.
I think this is wrong. Logical slots also preserve resources other than WAL.
I also think that the complaint about slots not being something to receive
from is simply wrong for logical slots.Uh, can you clarify since I can't find details on what they preserve.
Slots (physical ones can, logical ones always do), prevent row cleanup on the
primary.
The reason I liked the new wording is that the slot is only a small part
of the receiving path. Almost by definition, the slot is specified as
_part_ of the connection parameter --- it is not the connection
parameter.
I don't know what that has to do with anything.
Can you think of better wording that would be clearer than what we had?
I don't see any need to revise the wording of the changed sections.
Greetings,
Andres Freund
On Fri, Nov 14, 2025 at 09:25:20AM -0500, Andres Freund wrote:
Hi,
On 2025-11-14 09:12:33 -0500, Bruce Momjian wrote:
On Fri, Nov 14, 2025 at 09:05:07AM -0500, Andres Freund wrote:
Hi,
On 2025-11-14 09:02:12 -0500, Andres Freund wrote:
On 2025-11-14 13:56:06 +0000, Bruce Momjian wrote:
doc: remove verbiage about "receiving" data from rep. slots
The slots are just LSN markers, not something to receive from.
I think this is wrong. Logical slots also preserve resources other than WAL.
I also think that the complaint about slots not being something to receive
from is simply wrong for logical slots.Uh, can you clarify since I can't find details on what they preserve.
Slots (physical ones can, logical ones always do), prevent row cleanup on the
primary.
I see your point. How is the attached patch? The link right after the
modified text talks only about WAL retention, so I think we need
something in this sentence to say we do more than WAL retention for
logical replication slots.
--
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.
Attachments:
slot.difftext/x-diff; charset=us-asciiDownload+3-2
Hi,
On 2025-11-14 09:49:02 -0500, Bruce Momjian wrote:
On Fri, Nov 14, 2025 at 09:25:20AM -0500, Andres Freund wrote:
Hi,
On 2025-11-14 09:12:33 -0500, Bruce Momjian wrote:
On Fri, Nov 14, 2025 at 09:05:07AM -0500, Andres Freund wrote:
Hi,
On 2025-11-14 09:02:12 -0500, Andres Freund wrote:
On 2025-11-14 13:56:06 +0000, Bruce Momjian wrote:
doc: remove verbiage about "receiving" data from rep. slots
The slots are just LSN markers, not something to receive from.
I think this is wrong. Logical slots also preserve resources other than WAL.
I also think that the complaint about slots not being something to receive
from is simply wrong for logical slots.Uh, can you clarify since I can't find details on what they preserve.
Slots (physical ones can, logical ones always do), prevent row cleanup on the
primary.I see your point. How is the attached patch? The link right after the
modified text talks only about WAL retention, so I think we need
something in this sentence to say we do more than WAL retention for
logical replication slots.
It's less wrong, but I don't think this is the right place to add more
documentation about what replication slots do.
Greetings,
Andres Freund
On Fri, Nov 14, 2025 at 09:55:37AM -0500, Andres Freund wrote:
Hi,
On 2025-11-14 09:49:02 -0500, Bruce Momjian wrote:
On Fri, Nov 14, 2025 at 09:25:20AM -0500, Andres Freund wrote:
Hi,
On 2025-11-14 09:12:33 -0500, Bruce Momjian wrote:
On Fri, Nov 14, 2025 at 09:05:07AM -0500, Andres Freund wrote:
Hi,
On 2025-11-14 09:02:12 -0500, Andres Freund wrote:
On 2025-11-14 13:56:06 +0000, Bruce Momjian wrote:
doc: remove verbiage about "receiving" data from rep. slots
The slots are just LSN markers, not something to receive from.
I think this is wrong. Logical slots also preserve resources other than WAL.
I also think that the complaint about slots not being something to receive
from is simply wrong for logical slots.Uh, can you clarify since I can't find details on what they preserve.
Slots (physical ones can, logical ones always do), prevent row cleanup on the
primary.I see your point. How is the attached patch? The link right after the
modified text talks only about WAL retention, so I think we need
something in this sentence to say we do more than WAL retention for
logical replication slots.It's less wrong, but I don't think this is the right place to add more
documentation about what replication slots do.
Patch applied. I can keep improving it as we get more ideas.
--
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.
On 2025-11-14 10:46:30 -0500, Bruce Momjian wrote:
On Fri, Nov 14, 2025 at 09:55:37AM -0500, Andres Freund wrote:
On 2025-11-14 09:49:02 -0500, Bruce Momjian wrote:
On Fri, Nov 14, 2025 at 09:25:20AM -0500, Andres Freund wrote:
Hi,
On 2025-11-14 09:12:33 -0500, Bruce Momjian wrote:
On Fri, Nov 14, 2025 at 09:05:07AM -0500, Andres Freund wrote:
Hi,
On 2025-11-14 09:02:12 -0500, Andres Freund wrote:
On 2025-11-14 13:56:06 +0000, Bruce Momjian wrote:
doc: remove verbiage about "receiving" data from rep. slots
The slots are just LSN markers, not something to receive from.
I think this is wrong. Logical slots also preserve resources other than WAL.
I also think that the complaint about slots not being something to receive
from is simply wrong for logical slots.Uh, can you clarify since I can't find details on what they preserve.
Slots (physical ones can, logical ones always do), prevent row cleanup on the
primary.I see your point. How is the attached patch? The link right after the
modified text talks only about WAL retention, so I think we need
something in this sentence to say we do more than WAL retention for
logical replication slots.It's less wrong, but I don't think this is the right place to add more
documentation about what replication slots do.Patch applied. I can keep improving it as we get more ideas.
I'm rather baffled by the process here. You pushed a patch, without any
review, which also wasn't previously posted publicly, that made things
worse. Then, after you got pushback on that change, you posted another patch,
that got mildly negative feedback. Then you also pushed that change.
On Fri, Nov 14, 2025 at 12:14:15PM -0500, Andres Freund wrote:
Patch applied. I can keep improving it as we get more ideas.
I'm rather baffled by the process here. You pushed a patch, without any
review, which also wasn't previously posted publicly, that made things
worse. Then, after you got pushback on that change, you posted another patch,
that got mildly negative feedback. Then you also pushed that change.
Well, we talked privately on chat and I gave my reasons why I thought
the additional detail was helpful. When you stopped replying, I thought
that meant you were happy with the change, or had no ideas for
improvement. Obviously my assumption was wrong. As I stated, I am open
to continue improving it.
To reiterate what I said on private chat, our only docs about
replication slots are here:
https://www.postgresql.org/docs/devel/warm-standby.html#STREAMING-REPLICATION-SLOTS
It mostly talks about retaining WAL, and I cleaned that up to specify
the cases where only physical replication was involved. (You can see
yesterday's commits in the output.) Logical replication does more than
just retain WAL, and since we were only referencing the above
WAL-retention chapter from the subscription chapter:
https://www.postgresql.org/docs/devel/warm-standby.html#STREAMING-REPLICATION-SLOTS
I added a mention of "track relevant transaction activity". If that is
wrong, what is the right wording that adds details beyond WAL retention?
I personally was confused about replication slots, so I assumed these
changes will help others.
--
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.
On Fri, Nov 14, 2025 at 12:14 PM Andres Freund <andres@anarazel.de> wrote:
I'm rather baffled by the process here. You pushed a patch, without any
review, which also wasn't previously posted publicly, that made things
worse. Then, after you got pushback on that change, you posted another patch,
that got mildly negative feedback. Then you also pushed that change.
I'm not totally sure that we're in a worse place after these changes
than we were before them, but I strongly agree that committing a
change with no previous public discussion is a thing that generally
should not happen.
I mean, if the buildfarm is broken, pushing a fix quickly is
absolutely the right thing to do, but if you think the documentation
needs improving, there's no reason not to discuss that on
pgsql-hackers before pushing.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Wed, Nov 19, 2025 at 11:02:08AM -0500, Robert Haas wrote:
On Fri, Nov 14, 2025 at 12:14 PM Andres Freund <andres@anarazel.de> wrote:
I'm rather baffled by the process here. You pushed a patch, without any
review, which also wasn't previously posted publicly, that made things
worse. Then, after you got pushback on that change, you posted another patch,
that got mildly negative feedback. Then you also pushed that change.I'm not totally sure that we're in a worse place after these changes
than we were before them, but I strongly agree that committing a
change with no previous public discussion is a thing that generally
should not happen.I mean, if the buildfarm is broken, pushing a fix quickly is
absolutely the right thing to do, but if you think the documentation
needs improving, there's no reason not to discuss that on
pgsql-hackers before pushing.
Yeah, I was trying to clean up what we had and I thought it was
no-controversial. Obviously I was wrong.
--
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.