On Mon, Oct 19, 2026 at 7:19 PM Manu <[email protected]> wrote:
> 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 > Hi Manu, Even after resyncing data from scratch Still I am experiencing the same issue. I see the logical slot lag 300Gb again after the initial copy is done. Seems we need more network bandwidth to handle this. Here this is expected with huge update operations on a single non partition table when the logical slot holds a huge amount of data to replicate from source to target. Decoding is the single threaded which is unable to handle efficiently. No blocking and locking and long running and open transactions at both sides. Would it be possible to fix by doing following steps * Increase the bandwidth * Hash partitioning on that table I have twenty tables listed in publication so here only one table has huge updates but not the rest of the tables (very less DML's). In this case splitting the tables into multiple publications is not the permanent solution. Even in sixteen version no improvements for replication performance Regards, Durga Mahesh
