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

From: shveta malik <shveta(dot)malik(at)gmail(dot)com>
To: SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, shveta malik <shveta(dot)malik(at)gmail(dot)com>
Subject: Re: [Patch]: Fix excessive ProcArrayLock acquisitions with subscription max_retention_duration=0
Date: 2026-04-27 09:48:23
Message-ID: CAJpy0uDGM8eVqMORHKw61mm24AjH7jPZAhUaN3YeJrZ1bdpQFQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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
Shveta

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bertrand Drouvot 2026-04-27 10:01:17 Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE
Previous Message Peter Eisentraut 2026-04-27 09:40:15 Re: Inconsistent trigger behavior between two temporal leftovers