Re: Add progressive backoff to XactLockTableWait functions

From: Xuneng Zhou <xunengzhou(at)gmail(dot)com>
To: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Andres Freund <andres(at)anarazel(dot)de>
Cc: Kevin K Biju <kevinkbiju(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Add progressive backoff to XactLockTableWait functions
Date: 2025-07-04 08:57:22
Message-ID: CABPTF7UTPmEXZFvvUEdn1O4iUqZyJd3uG00Pr+uqkkKqgh8SXQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Thu, Jul 3, 2025 at 9:30 AM Xuneng Zhou <xunengzhou(at)gmail(dot)com> 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.
>> >
>> > Right.
>> >
>> >> But are you suggesting that this doesn't need to be addressed?
>> >
>> > No.
>> >
>> >> Or do you have another idea for how to handle it?
>> >
>> > We have all the information to make it work properly on standby. I've
>> not find through the code to figure out not, but that's what needs to
>> happen, instead on putting on another layer of hacks.
>>
>> Sorry, maybe I failed to get your point...
>> Could you explain your idea or reasoning in a bit more detail?
>>
>
> My take is that XactLockTableWait() isn’t really designed to work on
> standby. Instead of adding another layer on top like v4 did, maybe we can
> tweak the function itself to support standby. One possible approach could
> be to add a check like RecoveryInProgress() to handle the logic when
> running on a standby.
>

After thinking about this further, Andres's suggestion might be replacing
polling(whether smart or not) with event-driven like waiting in
XactLockTableWait. To achieve this, implementing a new notification
mechanism for standby servers seems to be required. From what I can
observe, the codebase appears to lack IPC infrastructure for waiting on
remote transaction completion and receiving notifications when those
transactions finish. I'm not familiar with this area, so additional inputs
would be very helpful here.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message 邱宇航 2025-07-04 09:22:31 Wrong off type in smgrfd and mdfd
Previous Message Fujii Masao 2025-07-04 08:45:46 Re: A assert failure when initdb with track_commit_timestamp=on