' every On Sat, Jul 11, 2026 at 12:46 PM vignesh C <[email protected]> wrote: > > On Sat, 11 Jul 2026 at 10:31, Amit Kapila <[email protected]> wrote: > > > > On Fri, Jul 10, 2026 at 10:22 AM Noah Misch <[email protected]> wrote: > > > > > > A Fable 5 review of logical replication of sequences found a way to get > > > subscribed sequences into READY state despite the subscriber side having > > > data > > > older than the last REFRESH SEQUENCES. I'm attaching the test case it > > > wrote. > > > I reviewed the test, and I think it identifies a genuine defect. > > > > > > > Good catch. We have following ways to fix: (a) As mentioned by > > Kuroda-san, during REFRESH SEQUENCES command, if we detect that the > > sequencesync worker is in progress, we can either make the command > > wait till the sequencesync is finished, return ERROR suggesting > > sequence sync already in-progress, or first stop the sequencesync > > worker and then complete the command and let the worker restart after > > REFRESH command is finished; (b) raise a WARNING+HINT for sequences > > that are not in ready state as proposed by Vignesh. Shall we > > additionally add a Note for user to ensure seuencesync worker is not > > in-progress before REFRESH SEQUENCES command? > > > > Do you have any preference? I think WARNING+HINT should be sufficient > > for users as this shouldn't be a common scenario but going the other > > way is also fine. > > Both approaches seem reasonable to me. One downside of the WARNING > approach is that if a subscription contains many sequences and the > user immediately reruns ALTER SUBSCRIPTION ... REFRESH SEQUENCES, they > could receive a large number of warnings one for each sequence that is > already being synchronized which may be noisy and not particularly > useful.
Right. > 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. 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. thanks Shveta
