On Thu, Sep 18, 2025 at 5:20 PM Ashutosh Sharma <ashu.coe...@gmail.com> wrote: > > Hi Ajin, > > On Thu, Sep 18, 2025 at 4:16 PM Ajin Cherian <itsa...@gmail.com> wrote: > > > > On Fri, Sep 12, 2025 at 1:56 PM shveta malik <shveta.ma...@gmail.com> wrote: > > > > > > The approach seems valid and should work, but introducing a new file > > > like promote.inprogress for this purpose might be excessive. We can > > > first try analyzing existing information to determine whether we can > > > distinguish between the two scenarios -- a primary in crash recovery > > > immediately after a promotion attempt versus a regular primary. If we > > > are unable to find any way, we can revisit the idea. > > > > > > > I needed a way to reset slots not only during promotion, but also > > after a crash that occurs while slots are being reset, so there would > > be a fallback mechanism to clear them again on startup. As Shveta > > pointed out, it wasn’t trivial to tell apart a standby restarting > > after crashing during promotion from a primary restarting after a > > crash. So I decided to just reset slots every time primary (or a > > standby after promotion) restarts. > > > > Because this fallback logic will run on every primary restart, it was > > important to minimize overhead added by the patch. After some > > discussion, I placed the reset logic in RestoreSlotFromDisk(), which > > is invoked by StartupReplicationSlots() whenever the server starts. > > Because RestoreSlotFromDisk() already loops through all slots, this > > adds minimum extra work; but also ensures the synced flag is cleared > > when running on a primary. > > > > The next challenge was finding a reliable flag to distinguish > > primaries from standbys, since we really don’t want to reset the flag > > on a standby. I tested StandbyMode, RecoveryInProgress(), and > > InRecovery. But during restarts, both RecoveryInProgress() and > > InRecovery are always true on both primary and standby. In all my > > testing, StandbyMode was the only variable that consistently > > differentiated between the two, which is what I used. > > > > +/* > + * ResetSyncedSlots() > + * > + * Reset all replication slots that have synced=true to synced=false. > + */ > > I feel this is not correct, we are force resetting sync flag status > for all logical slots, not just the one that is set to true. >
You may ignore this, it's actually resetting only the synced slots. Sorry for the noise. -- With Regards, Ashutosh Sharma.
