Re: Add progressive backoff to XactLockTableWait functions
Fujii Masao <masao.fujii@oss.nttdata.com>
From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: Andres Freund <andres@anarazel.de>
Cc: Xuneng Zhou <xunengzhou@gmail.com>, Kevin K Biju <kevinkbiju@gmail.com>,
pgsql-hackers@lists.postgresql.org
Date: 2025-07-02T14:15:09Z
Lists: pgsql-hackers
On 2025/07/02 23:04, Andres Freund wrote: > Hi, > > On 2025-07-02 22:55:16 +0900, Fujii Masao wrote: >> On 2025/06/24 1:32, Xuneng Zhou wrote: >>> 3. The proposed solution >>> >>> If the above analysis is sound, one potential fix would be to add >>> separate branching for standby in XactLockTableWait. However, this seems >>> inconsistent with the function's definition—there's simply no lock entry >>> in the lock table for waiting. We could implement a new function for >>> this logic, >> >> To be honest, I'm fine with v3, since it only increases the sleep time >> after 5000 loop iterations, which has negligible performance impact. > > I think this is completely the wrong direction. We should make > XactLockTableWait() on standbys, not make the polling smarter. On standby, XactLockTableWait() can enter a busy loop with 1ms sleeps. But are you suggesting that this doesn't need to be addressed? Or do you have another idea for how to handle it? Regards, -- Fujii Masao NTT DATA Japan Corporation
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Allow logical decoding on standbys
- 0fdab27ad68a 16.0 cited