sql,log: also include the stmt tag in query logs #64871
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This change is |
Release note (sql change): The statement type ("tag") is now also
included alongside the full text of the SQL query in the various
structured log entries produced when query execution is being logged.
|
TFYR! bors r=rafiss |
|
Build succeeded: |
craig bot
pushed a commit
that referenced
this pull request
May 21, 2021
64894: sql/event_log: reduce tech debt, simplify and fix bugs r=rafiss a=knz Fixes #64685. First commit from #64871. Prior to this patch, there was a little mess in `sql/event_log.go` that had been introduced when "optimizing" GRANT/REVOKE to only use one write batch for all the events logged: - a lot of code had been duplicated; - the control flow had been rendered more complex; - the API interface for the functions in event_log.go were complex to use, requiring callers to provide descriptor IDs and structured events as separate slices; - the optimizing logic was not properly applied to the other case where multiple events are emitted: SQL audit logging in `exec_log.go`. This patch streamlines this by reducing `event_log.go` back to its simpler form: an overall event refinement pipeline with a straightforward control flow. To guide future maintainers, the patch also adds an explanatory comment at the top of the file that sketches the overall structure of the pipeline. Finally, this patch fixes a bug introduced when query logging started using structured events: the ability to automatically copy all the execution events to the DEV channel when setting the `vmodule` setting to `exec_log=2` (or above). In addition to fixing that bug, the following new vmodule-based abilities are added: - events for DDL statements and others that call `logEvent()` can now be collected in the DEV channel by using the name of the source file where they were generated as filter (e.g. `vmodule=create_table=2` for the CREATE TABLE events. - events of other kinds can be collected in the DEV channel by setting `vmodule=event_log=2`. (Note a subtle difference between `vmodule=create_table=2` and `vmodule=exec_log=2`: the former emits the event to the DEV channel while the stmt is executed; the latter emits the event after the stmt completes. If both are enabled, TWO events are sent to the DEV channel.) Since all the vmodule filtering options are subject to change without notice between versions, we do not wish to document these nuances. For this reason, the release note below is left blank. Release note: None Co-authored-by: Raphael 'kena' Poss <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This was requested from a customer through a case handled by @pxlogan
Release note (sql change): The statement type ("tag") is now also
included alongside the full text of the SQL query in the various
structured log entries produced when query execution is being logged.