Fix xid_advance_interval when max_retention_duration is 0.

When a subscription has retain_dead_tuples enabled and maxretention is
zero (unlimited), adjust_xid_advance_interval() mistakenly caps
xid_advance_interval to zero.

This zero interval forces get_candidate_xid() to evaluate
TimestampDifferenceExceeds() as always true, causing the apply worker to
call GetOldestActiveTransactionId() for every WAL message. This
leads to unnecessary ProcArrayLock acquisitions.

Fix this by only capping the interval when maxretention > 0, allowing
the exponential back-off to function properly.

Author: SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>
Reviewed-by: shveta malik <shveta.malik@gmail.com>
Reviewed-by: Nisha Moond <nisha.moond412@gmail.com>
Discussion: https://postgr.es/m/CAHg+QDdKVnCLHot=AcoPpEiSyDzGz7wGYjAFHVOw57oDtmUDWQ@mail.gmail.com

diff --git a/src/backend/replication/logical/worker.c b/src/backend/replication/logical/worker.c
index 9f2a16b17fa99faccec9ec5619087c18a669f3ee..dd6fc38a41ea083c58514650e391396da7e6ebdd 100644 (file)
--- a/src/backend/replication/logical/worker.c
+++ b/src/backend/replication/logical/worker.c
@@ -4997,9 +4997,10 @@ adjust_xid_advance_interval(RetainDeadTuplesData *rdt_data, bool new_xid_found)
 
        /*
         * Ensure the wait time remains within the maximum retention time limit
-        * when retention is active.
+        * when retention is active.  Skip this cap when maxretention is zero,
+        * which means unlimited retention (no timeout).
         */
-       if (MySubscription->retentionactive)
+       if (MySubscription->retentionactive && MySubscription->maxretention > 0)
                rdt_data->xid_advance_interval = Min(rdt_data->xid_advance_interval,
                                                                                         MySubscription->maxretention);
 }