Skip to content
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

executor: remove default search time range of cluster_log when query without time range. (#16938) #17003

Merged
merged 2 commits into from
May 14, 2020

Conversation

sre-bot
Copy link
Contributor

@sre-bot sre-bot commented May 7, 2020

cherry-pick #16938 to release-4.0


What problem does this PR solve?

Before this PR, when query the cluster_log table, if the user doesn't specify the time range, the default behavior is searching the recent 30 minutes logs, But DBA think this is not right, maybe return an error when the user query cluster_log doesn't specify the time range, just as below:

mysql>select * from `CLUSTER_LOG`
(1105, u"denied to scan logs, please specified the start time, such as `time > '2020-01-01 00:00:00'`")
mysql>select * from `CLUSTER_LOG` where time > "2020-04-28 17:00:10"
(1105, u"denied to scan logs, please specified the end time, such as `time < '2020-01-01 00:00:00'`")
mysql>select * from `CLUSTER_LOG` where time > "2020-04-28 17:00:10" and time < '2020-04-28 18:00:00'
(1105, u"denied to scan full logs (use `SELECT * FROM cluster_log WHERE message LIKE '%'` explicitly if intentionally)")

How it Works:

Related changes

  • Need to cherry-pick to the release branch

Check List

Tests

  • Unit test

Side effects

  • Breaking backward compatibility

Release note

  • Remove the default search time range of cluster_log when querying without time range.

@sre-bot sre-bot requested review from a team as code owners May 7, 2020 02:46
@sre-bot
Copy link
Contributor Author

sre-bot commented May 7, 2020

/run-all-tests

@Deardrops
Copy link
Contributor

/rebuild

Copy link
Member

@zz-jason zz-jason left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@zz-jason zz-jason added the status/LGT1 Indicates that a PR has LGTM 1. label May 7, 2020
@bb7133 bb7133 modified the milestones: v4.0.0-rc.1, 4.0.0-rc.2 May 9, 2020
Copy link
Contributor

@Deardrops Deardrops left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@wshwsh12 wshwsh12 added status/LGT2 Indicates that a PR has LGTM 2. and removed status/LGT1 Indicates that a PR has LGTM 1. labels May 13, 2020
@zz-jason zz-jason added the status/can-merge Indicates a PR has been approved by a committer. label May 14, 2020
@sre-bot
Copy link
Contributor Author

sre-bot commented May 14, 2020

Your auto merge job has been accepted, waiting for:

  • 17118
  • 17107
  • 16165

@sre-bot
Copy link
Contributor Author

sre-bot commented May 14, 2020

/run-all-tests

@sre-bot sre-bot merged commit 528c0d3 into pingcap:release-4.0 May 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
sig/execution SIG execution status/can-merge Indicates a PR has been approved by a committer. status/LGT2 Indicates that a PR has LGTM 2. type/4.0-cherry-pick
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants