On Fri, 2 May 2025 at 10:11, Xuneng Zhou <xunengz...@gmail.com> wrote: > > Hi, > Is this an expected behavior? > > A race between subscriber LSN feedback and publisher subscription change > processing allows the walsender to restart decoding past relevant WAL > records, bypassing the updated subscription rules for those records.
We have three processes involved in this scenario: A walsender process on the publisher, responsible for decoding and sending WAL changes. An apply worker process on the subscriber, which applies the changes. A session executing the ALTER SUBSCRIPTION command. Due to the asynchronous nature of these processes, the ALTER SUBSCRIPTION command may not be immediately observed by the apply worker. Meanwhile, the walsender may process and decode an INSERT statement. If the insert targets a table (e.g., tab_3) that does not belong to the current publication (pub1), the walsender silently skips replicating the record and advances its decoding position. This position is sent in a keepalive message to the subscriber, and since there are no pending transactions to flush, the apply worker reports it as the latest received LSN. Later, when the apply worker eventually detects the subscription change, it restarts—but by then, the insert has already been skipped and is no longer eligible for replay, as the table was not part of the publication (pub1) at the time of decoding. This race condition arises because the three processes run independently and may progress at different speeds due to CPU scheduling or system load. Thoughts? Regards, Vignesh
