On 2025/07/02 23:19, Andres Freund wrote:
Hi,
On July 2, 2025 10:15:09 AM EDT, Fujii Masao <masao.fu...@oss.nttdata.com>
wrote:
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.
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?
Regards,
--
Fujii Masao
NTT DATA Japan Corporation
