Re: Regarding huge logical slot lag between source and target

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