Re: Add progressive backoff to XactLockTableWait functions

Поиск
Список
Период
Сортировка
Искать
От
Fujii Masao
Тема
Re: Add progressive backoff to XactLockTableWait functions
Дата
Msg-id
0a2f1fef-8fe9-48c0-ba5d-9499dc7c8f2f@oss.nttdata.com
Ответ на
Список
Дерево обсуждения
Add progressive backoff to XactLockTableWait functions Xuneng Zhou <xunengzhou@gmail.com>
Re: Add progressive backoff to XactLockTableWait functions Fujii Masao <masao.fujii@oss.nttdata.com>
Re: Add progressive backoff to XactLockTableWait functions Xuneng Zhou <xunengzhou@gmail.com>
Re: Add progressive backoff to XactLockTableWait functions Andres Freund <andres@anarazel.de>
Re: Add progressive backoff to XactLockTableWait functions Xuneng Zhou <xunengzhou@gmail.com>


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



В списке pgsql-hackers по дате отправления
От: jian he
Дата:
От: Jianghua Yang
Дата:
FAQ