|
Given the concerns about the volume of log messages that might result from this, we have decided not to implement this and instead are going to rely on SERVER-39985 and SERVER-40329 to provide the information that customers need to diagnose transaction failures due to write conflicts or inability to acquire a lock within the 5ms timeout.
|
|
judah.schvimer, this request was initially prompted by a customer scenario involving lock acquisition timeout, and it was difficult to identify the conflicting lock holder because the failing transactions were not logged. My guess is we wouldn't spam the logs if we logged transactions that failed for that reason (but did not log transactions that failed due to write conflict) - what do you think?
|
|
Request to add "comment" parameter from SERVER-39955 to the log message.
|
|
The use case is being able to debug repeated transaction failures during retries due to lock conflicts without reducing the `slowOpThresholdMS` below 5ms and thus potentially spamming the logs even more. I agree that logging all failed transaction statements could spam the logs under certain workloads. I propose that we log this at log level 1 or higher, not at the default log level.
|
|
bruce.lucas, we're concerned this will spam the logs, especially for workloads that expect write conflicts and retries. What is your use case?
|
Generated at Thu Feb 08 04:53:42 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.