Instead, wouldn't it be simpler to update LockAcquireExtended() to
take a new argument, like logLockFailure, to control whether
a lock failure should be logged directly? I’ve adjusted the patch
accordingly and attached it. Please let me know what you think!

Regards,
Thank you!

It's very simple and nice.
It seems like it can also handle other lock failure cases by extending logLockFailure.

I agree with this propose.


Regards,



Reply via email to