Hi Durga, > Now slot lag is very minimal. > How did you rectify when same issue you faced rather than resync data > from scratch.
Glad it is minimal now. To be clear, I did not hit this on a production system -- I reproduced the pattern in a lab to find the cause, so there was nothing to "rectify" there. But that is the useful part: this kind of lag is a throughput deficit, not corruption. The slot's restart_lsn is simply trailing confirmed_flush, so it drains on its own once the subscriber catches up -- when the write load eases or the bottleneck is removed. A resync only buys you anything when there is real divergence on the subscriber, which this is not; it just resets the clock and the lag comes back under the same load. So if it grows again, the order is: find the bottleneck first (top on the walsender on the source and on the apply worker on the target -- whichever is near 100% of a core is the limit), then apply the matching lever: lower the commit rate reaching the hot table, split the tables across several subscriptions so more apply workers run in parallel, or give the subscriber more CPU/IO. No resync needed. Regards, Manu
