On Mon, Jul 13, 2026 at 9:35 AM shveta malik <[email protected]> wrote: > > On Sat, Jul 11, 2026 at 12:46 PM vignesh C <[email protected]> wrote: > > > > > Here is a patch implementing approach (a), which detects whether a > > sequence synchronization worker is already running for the > > subscription. If a synchronization is already in progress, ALTER > > SUBSCRIPTION ... REFRESH SEQUENCES reports an error and asks the user > > to rerun the command after the current synchronization completes. > > > > As I suggested earlier, I think this approach is preferable. > > One potential issue I anticipate is the following: if sequence > synchronization repeatedly fails due to an error that the user is not > concerned about (for example, some sequences are missing on the > publisher), the worker may keep getting started and exiting every few > seconds. If the user happens to retry ALTER SUBSCRIPTION ... REFRESH > SEQUENCES while those worker retries are in progress, they may > repeatedly fail with the new error because the worker keeps getting > restarted. Thus, the user may not easily get the sequences that matter > to sync again. It's difficult to predict how likely this scenario is, > but if the overall situation itself is rare, I think the current > suggested solution should be acceptable. >
Yeah, I think this is no different than other ERRORs, one can get during apply like a constraint violation. The way to break the repeated restart loop is that users need to figure out that by checking LOGs or may be conflict related information if we ever detect this as a conflict. So, I agree that even in this situation giving ERROR on REFRESH SEQUENCES is reasonable. > Another potential solution, slightly more complex than the previous > one, but which could completely avoid such race scenarios is by > introducing a new DATASYNC state. Before starting sequence > synchronization, the worker would move the affected sequences to > DATASYNC. If ALTER SUBSCRIPTION ... REFRESH SEQUENCES is executed > concurrently, it would reset their state back to INIT. Before marking > a sequence as READY, the worker would recheck its current state; if it > finds that the state has been reset to INIT, it would simply skip > synchronizing that sequence. Since the sequence remains in the INIT > state, it will automatically be picked up during the next > synchronization cycle. This avoids applying stale sequence values > while ensuring that fresh values are fetched from the publisher during > the subsequent synchronization attempt. > Hmm, yeah, this is another version (with a bit of additional complexity) of auto sync as discussed in my response. I think if we later decide to go in this direction, we may want to achieve it via some generation_number kind of concept where the command will indicate somewhere in shared memory that one sync cycle is required. -- With Regards, Amit Kapila.
