Re: Add progressive backoff to XactLockTableWait functions

>
> Thanks for the feedbacks!

To be honest, I'm fine with v3, since it only increases the sleep time
> after 5000 loop iterations, which has negligible performance impact.
> But if these functions aren't intended to be used during recovery and
> the loop shouldn't reach that many iterations, I'm also okay with
> the v4 approach of introducing a separate function specifically for
> recovery.
>
> But this amakes me wonder if we should add something like
> Assert(!RecoveryInProgress()) to those two functions, to prevent them
> from being used during recovery in the future.
>
> > but it's hard to find a proper place for it to fit well: lmgr.c is for
> locks, while standby.c or procarray.c are not that ideal either. Therefore,
> I placed the special handling for standby in SnapBuildWaitSnapshot.
>
> Since the purpose and logic of the new function are similar to
> XactLockTableWait(), I think it would be better to place it nearby
> in lmgr.c, even though it doesn't handle a lock directly. That would
> help keep the related logic together and improve readability.
>

Now I see two possible approaches here. One is to extend
XactLockTableWait(), and the other is to introduce a new wait function
specifically for standby. For the first option, adding standby-specific
logic might not align well with the function’s name or its original design.
If we go with a new function, we might need to consider what other
scenarios it could be reused in. If this is the only place it would apply,
whether it’s worth introducing a separate function just for this case.

Best regards,
Xuneng

>