Re: [Patch]: Fix excessive ProcArrayLock acquisitions with subscription max_retention_duration=0

From: SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com>
To: shveta malik <shveta(dot)malik(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Subject: Re: [Patch]: Fix excessive ProcArrayLock acquisitions with subscription max_retention_duration=0
Date: 2026-04-27 17:02:41
Message-ID: CAHg+QDfQEX5b=4MB=67WgPrF4t8gyUMWyFp7-hFe=EAFW-qALA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Mon, Apr 27, 2026 at 2:48 AM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:

> On Mon, Apr 27, 2026 at 2:11 PM SATYANARAYANA NARLAPURAM
> <satyanarlapuram(at)gmail(dot)com> wrote:
> >
> > Hi Hackers,
> >
> > When a subscription has retain_dead_tuples enabled with maxretention set
> > to zero (unlimited retention), adjust_xid_advance_interval() caps
> > xid_advance_interval to Min(interval, maxretention). Since maxretention
> > is zero, this always collapses the interval to zero milliseconds.
> >
> > A zero makes TimestampDifferenceExceeds(last_time, now, 0) always
> > true in get_candidate_xid(). This causes the apply worker to call
> > GetOldestActiveTransactionId() on every single WAL message. This results
> in
> > a huge number of ProcArrayLock acquisitions under moderate write load.
> >
> > Fix by adding a maxretention > 0 guard to the cap. When maxretention is
> zero ,
> > the exponential back-off in adjust_xid_advance_interval()
> > now works correctly, growing the interval from 100 ms toward the 180 s
> > ceiling.
> >
> > Measured with perf uprobe counting GetOldestActiveTransactionId calls
> > at ~39K TPS (pgbench, 5 clients):
> >
> > Before fix: 25,104 calls / 5 s (~5,021/s)
> > After fix: 31 calls / 5 s (~6/s)
> >
>
> Thanks for reporting it. I am reveiwing the problem sattement.
> Meanwhile can you please look at it, I am getting the following error
> while applying the patch on my Ubuntu setup (git am):
>
> error: corrupt patch at line 22
>

Thanks! Please find the updated v2 patch.

Attachment Content-Type Size
v2-0001-Fix-apply-worker-busy-loop-when-subscription-max_ret.patch application/octet-stream 1.9 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message lakshmi 2026-04-27 17:10:21 Re: Use log_newpage_range in HASH index build
Previous Message Marco Nenciarini 2026-04-27 16:50:28 Re: BUG: Cascading standby fails to reconnect after falling back to archive recovery