On Tue, Feb 24, 2026 at 4:07 PM Dilip Kumar <[email protected]> wrote: > > On Mon, Feb 23, 2026 at 11:14 AM Hayato Kuroda (Fujitsu) > <[email protected]> wrote: > > > > Dear Dilip, > > > > > Thanks for clarifying the use case, and I agree this is a valid use > > > case, although I am not completely sure how exactly we are achieving > > > that? I mean sequence sync workers need to fetch the list of all > > > published sequences to identify whether they are in sync with the > > > local sequence state or not? Or somehow we can avoid that? If not > > > what we would save, updating the local states of the sequences if they > > > are already in sync? > > > > IIUC, the sequencesync worker first lists all sequences on the subscriber, > > then > > gets their states on the publisher side. Then the worker updates the state > > only > > when the sequence between instances is different. > > > > Does it make sense for you? > > Thanks, yeah that absolutely makes sense, one of the key requirement > while using the logical replication for the major version upgrade is > how long is the downtime before switchover and thats directly > proportional to the time we take in syncing. So with automatic > sequence sync if we are ensuring that only the sequences which were > not synced automatically are synced with REFRESH that then this would > be very good feature addition. However, I will look into the patch to > see how we are taking care of syncing the sequences which are not > already synced. >
This is done by comparing local and remote sequence values. Have we done any time measurement with very large > number of sequences, that how much time REFRESH SEQUENCES takes with > or without patch? Even if done, nothing is shared on -hackers. So, we should do some measurement in this regard, if not done already, and share the data. -- With Regards, Amit Kapila.
