New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sql: session tracing inside a txn is painful #23558
Labels
C-enhancement
Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)
Comments
andreimatei
added
the
C-enhancement
Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)
label
Mar 7, 2018
andreimatei
added a commit
to andreimatei/cockroach
that referenced
this issue
May 2, 2018
Before this patch, starting tracing while tracing was ongoing, as well as stopping tracing while it wasn't resulted in errors. Also, like all statements, running set tracing in an aborted transaction was an error. All these facts colluded to make tracing from a program around some code that might result in errors hilariously frustrating - you start tracing, then you may or may not get an error, then you want to stop tracing - but how do you stop? This patch makes it so that starting twice, stopping twice, or running set tracing after an error, is a-OK. Fixes cockroachdb#23558 Release note(sql): `set tracing=<mode>` became less finicky about the current session state, so that a client can more easily trace around statement that produce errors.
This is awesome. I ran straight into the issue you described while attempting to debug some TPCC-C performance issues and it was not fun. |
andreimatei
added a commit
to andreimatei/cockroach
that referenced
this issue
May 3, 2018
Before this patch, starting tracing while tracing was ongoing, as well as stopping tracing while it wasn't resulted in errors. Also, like all statements, running set tracing in an aborted transaction was an error. All these facts colluded to make tracing from a program around some code that might result in errors hilariously frustrating - you start tracing, then you may or may not get an error, then you want to stop tracing - but how do you stop? This patch makes it so that starting twice, stopping twice, or running set tracing after an error, is a-OK. Note that `set tracing=cluster;set tracing=cluster;set tracing=off` results in tracing being off (there's no counter for the nesting). Fixes cockroachdb#23558 Release note(sql): `set tracing=<mode>` became less finicky about the current session state, so that a client can more easily trace around statement that produce errors.
andreimatei
added a commit
to andreimatei/cockroach
that referenced
this issue
May 3, 2018
Before this patch, starting tracing while tracing was ongoing, as well as stopping tracing while it wasn't resulted in errors. Also, like all statements, running set tracing in an aborted transaction was an error. All these facts colluded to make tracing from a program around some code that might result in errors hilariously frustrating - you start tracing, then you may or may not get an error, then you want to stop tracing - but how do you stop? This patch makes it so that starting twice, stopping twice, or running set tracing after an error, is a-OK. Note that `set tracing=cluster;set tracing=cluster;set tracing=off` results in tracing being off (there's no counter for the nesting). Fixes cockroachdb#23558 Release note(sql): `set tracing=<mode>` became less finicky about the current session state, so that a client can more easily trace around statement that produce errors.
andreimatei
added a commit
to andreimatei/cockroach
that referenced
this issue
May 3, 2018
Before this patch, starting tracing while tracing was ongoing, as well as stopping tracing while it wasn't resulted in errors. Also, like all statements, running set tracing in an aborted transaction was an error. All these facts colluded to make tracing from a program around some code that might result in errors hilariously frustrating - you start tracing, then you may or may not get an error, then you want to stop tracing - but how do you stop? This patch makes it so that starting twice, stopping twice, or running set tracing after an error, is a-OK. Note that `set tracing=cluster;set tracing=cluster;set tracing=off` results in tracing being off (there's no counter for the nesting). Fixes cockroachdb#23558 Release note(sql): `set tracing=<mode>` became less finicky about the current session state, so that a client can more easily trace around statement that produce errors.
craig bot
pushed a commit
that referenced
this issue
May 3, 2018
25262: sql: make 'set tracing' just work r=andreimatei a=andreimatei Before this patch, starting tracing while tracing was ongoing, as well as stopping tracing while it wasn't resulted in errors. Also, like all statements, running set tracing in an aborted transaction was an error. All these facts colluded to make tracing from a program around some code that might result in errors hilariously frustrating - you start tracing, then you may or may not get an error, then you want to stop tracing - but how do you stop? This patch makes it so that starting twice, stopping twice, or running set tracing after an error, is a-OK. Fixes #23558 Co-authored-by: Andrei Matei <andrei@cockroachlabs.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
C-enhancement
Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)
If one uses, for example,
crdb.ExecuteTx()
and has code like the following:that's no good cause the final
set tracing=off
is rejected if the txn is in an error state. Moreover, starting tracing on that conn again fails. We should allowset tracing=off
in all states. Or something.Hacks like the following help, although tracing leaks on conns where it isn't stopped properly.
cc @petermattis
The text was updated successfully, but these errors were encountered: