[SERVER-39984] Log all failed transaction statements Created: 06/Mar/19  Updated: 28/Mar/19  Resolved: 28/Mar/19

Status: Closed
Project: Core Server
Component/s: Diagnostics
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Bruce Lucas (Inactive) Assignee: Tess Avitabile (Inactive)
Resolution: Won't Fix Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
related to SERVER-40329 Log all transactions at TXN verbosity... Closed
is related to SERVER-39955 Add support for a "comment" parameter... Closed
is related to SERVER-39985 Improve transaction lock failure erro... Closed
Sprint: Repl 2019-04-08
Participants:
Case:

 Description   

When diagnosing transaction failures due to issues such as write conflicts or inability to acquire a lock within the 5ms timeout it would be helpful if the failures were always logged even if they didn't exceed the slowms threshold.



 Comments   
Comment by Bruce Lucas (Inactive) [ 28/Mar/19 ]

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.

Comment by Bruce Lucas (Inactive) [ 25/Mar/19 ]

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?

Comment by James Kovacs [ 11/Mar/19 ]

Request to add "comment" parameter from SERVER-39955 to the log message.

Comment by James Kovacs [ 11/Mar/19 ]

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.

Comment by Judah Schvimer [ 11/Mar/19 ]

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.