On Fri, 22 Nov 2024 at 17:43, vignesh C <vignes...@gmail.com> wrote: > > On Thu, 21 Nov 2024 at 17:35, Nisha Moond <nisha.moond...@gmail.com> wrote: > > > > On Wed, Nov 20, 2024 at 1:29 PM vignesh C <vignes...@gmail.com> wrote: > > > > > > On Tue, 19 Nov 2024 at 12:43, Nisha Moond <nisha.moond...@gmail.com> > > > wrote: > > > > > > > > Attached is the v49 patch set: > > > > - Fixed the bug reported in [1]. > > > > - Addressed comments in [2] and [3]. > > > > > > > > I've split the patch into two, implementing the suggested idea in > > > > comment #5 of [2] separately in 001: > > > > > > > > Patch-001: Adds additional error reports (for all invalidation types) > > > > in ReplicationSlotAcquire() for invalid slots when error_if_invalid = > > > > true. > > > > Patch-002: The original patch with comments addressed. > > > > > > This Assert can fail: > > > > > > > Attached v50 patch-set addressing review comments in [1] and [2]. > > We are setting inactive_since when the replication slot is released. > We are marking the slot as inactive only if it has been released. > However, there's a scenario where the network connection between the > publisher and subscriber may be lost where the replication slot is not > released, but no changes are replicated due to the network problem. In > this case, no updates would occur in the replication slot for a period > exceeding the replication_slot_inactive_timeout. > Should we invalidate these replication slots as well, or is it > intentionally left out?
On further thinking, I felt we can keep the current implementation as is and simply add a brief comment in the code to address this. Additionally, we can mention it in the commit message for clarity. Regards, Vignesh
