On 2025/05/30 19:20, Peter Eisentraut wrote:
On 14.03.25 16:07, Fujii Masao wrote:
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.
Thanks for reviewing the patch!
I've made some minor cosmetic adjustments. The updated patch is attached.
Unless there are any objections, I'll proceed with committing it.
Pushed the patch. Thanks!
This patch added a setting "log_lock_failure", but the existing similar setting
"log_lock_waits" has a plural. Is there a reason for this difference?
No, Seino-san and I went with log_lock_failure at the time because
we didn't have a better name suggestion, and we figured we could
revisit the GUC name later if needed. so thanks for bringing it up again!
Otherwise, maybe "log_lock_failures" would be better.
Yes, this seems better for consistency with log_lock_waits.
Regards,
--
Fujii Masao
NTT DATA Japan Corporation
