On Sun, Jul 12, 2026 at 1:44 AM Noah Misch <[email protected]> wrote: > > On Sat, Jul 11, 2026 at 10:31:06AM +0530, Amit Kapila 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. > > I haven't formed a preference, but I would use these principles to decide. > Assume we eventually support continuous, WAL-decoded replication of sequences, > not just snapshot replication. Which choice would make sequence replication > behave most like table replication under the analogous concurrent actions? >
The other point that we could consider is a future extension of autosync sequences by allowing syncing at periodic intervals without user intervention. > If it's an ERROR, I'd probably omit the doc note, since the ERROR would be > clear and unsurprising. In general, there's no need to document everything > that causes an error. Documentation is most useful when an error is > surprising or affects how the user writes the application. > > If the command merely raises a WARNING, documentation becomes more important, > because warnings are easy to overlook. That is also an argument against a > WARNING: if the user must take action to avoid incorrect replicated state, it > is risky to rely on the user noticing one. > Sounds reasonable. Considering both your points, I am leaning towards option (a) (during REFRESH SEQUENCES command, if we detect that the sequencesync worker is in progress, we make the command return ERROR suggesting sequence sync is already in-progress). If in future auto sequence sync functionality is implemented, such an ERROR could still be appropriate because the auto sync should automatically take care of syncing. Or, we can even go in the direction that we can use this command to somehow immediately perform an auto sequence sync cycle instead of time-based re-sync. > Does that help? Yes, thanks. But share your suggestion if you disagree with the above or any other fix for the problem(s) reported by you. -- With Regards, Amit Kapila.
