Details
-
Task
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
None
Description
Hidden server parameter --log-slow-admin-statements
- is not a server variable
- is confusing with variable log_slow_filter=admin
The task would deprecate parameter log-slow-admin-statements, setting is default compile value to yes.
changing log_slow_filter to same usage as optimizer_switch using boolean mode
Reading word filter one expect that admin=yes or just admin means that the server filter admin statements.
What append today is the opposite and that's confusing in itself !
To be consistent we can rename log_slow_filter to log_slow_switch where admin=yes would mean that we don't filter admin statements.
The default would become log_slow_switch="admin=no" to get same content inside slow query log as today
Attachments
Activity
| Field | Original Value | New Value |
|---|---|---|
| Description |
Hidden server parameter --log-slow-admin-statements - is not a server variable - is confusing with variable log_slow_filter=admin i propose to deprecate parameter log-slow-admin-statements , and setting is default compile value to yes, changing log_slow_filter to similar variable as optimizer_switch using boolean mode Reading word filter one expect that admin=yes or just admin means that the server filter all DDL statement. What append today is the opposite and that's confusing in itself A more consistent view would be to rename log_slow_filter to slow_query_log_switch where admin=yes would mean that we don't filter DDL Statement . |
Hidden server parameter --log-slow-admin-statements - is not a server variable - is confusing with variable log_slow_filter=admin The task would deprecate parameter log-slow-admin-statements, setting is default compile value to yes. changing log_slow_filter to same usage as optimizer_switch using boolean mode Reading word filter one expect that admin=yes or just admin means that the server filter admin statements. What append today is the opposite and that's confusing in itself ! To be consistent we can rename log_slow_filter to log_slow_switch where admin=yes would mean that we don't filter admin statements. |
| Priority | Trivial [ 5 ] | Major [ 3 ] |
| Description |
Hidden server parameter --log-slow-admin-statements - is not a server variable - is confusing with variable log_slow_filter=admin The task would deprecate parameter log-slow-admin-statements, setting is default compile value to yes. changing log_slow_filter to same usage as optimizer_switch using boolean mode Reading word filter one expect that admin=yes or just admin means that the server filter admin statements. What append today is the opposite and that's confusing in itself ! To be consistent we can rename log_slow_filter to log_slow_switch where admin=yes would mean that we don't filter admin statements. |
Hidden server parameter --log-slow-admin-statements - is not a server variable - is confusing with variable log_slow_filter=admin The task would deprecate parameter log-slow-admin-statements, setting is default compile value to yes. changing log_slow_filter to same usage as optimizer_switch using boolean mode Reading word filter one expect that admin=yes or just admin means that the server filter admin statements. What append today is the opposite and that's confusing in itself ! To be consistent we can rename log_slow_filter to log_slow_switch where admin=yes would mean that we don't filter admin statements. The default would become log_slow_switch="admin=yes" |
| Description |
Hidden server parameter --log-slow-admin-statements - is not a server variable - is confusing with variable log_slow_filter=admin The task would deprecate parameter log-slow-admin-statements, setting is default compile value to yes. changing log_slow_filter to same usage as optimizer_switch using boolean mode Reading word filter one expect that admin=yes or just admin means that the server filter admin statements. What append today is the opposite and that's confusing in itself ! To be consistent we can rename log_slow_filter to log_slow_switch where admin=yes would mean that we don't filter admin statements. The default would become log_slow_switch="admin=yes" |
Hidden server parameter --log-slow-admin-statements - is not a server variable - is confusing with variable log_slow_filter=admin The task would deprecate parameter log-slow-admin-statements, setting is default compile value to yes. changing log_slow_filter to same usage as optimizer_switch using boolean mode Reading word filter one expect that admin=yes or just admin means that the server filter admin statements. What append today is the opposite and that's confusing in itself ! To be consistent we can rename log_slow_filter to log_slow_switch where admin=yes would mean that we don't filter admin statements. The default would become log_slow_switch="admin=no" to get same content inside slow query log as today |
| Fix Version/s | 10.2.0 [ 14601 ] |
| Workflow | defaullt [ 42341 ] | MariaDB v2 [ 43040 ] |
| Workflow | MariaDB v2 [ 43040 ] | MariaDB v3 [ 62074 ] |
| Fix Version/s | 10.2 [ 14601 ] |
| Workflow | MariaDB v3 [ 62074 ] | MariaDB v4 [ 130234 ] |
| Assignee | Daniel Black [ danblack ] |
| Fix Version/s | 10.12 [ 28320 ] |
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Summary | Better user experience with slow log filters | deprecate log-slow-admin-statements, Better user experience with slow log filters |
| Assignee | Daniel Black [ danblack ] | Andrew Hutchings [ JIRAUSER52179 ] |
| Status | In Progress [ 3 ] | In Review [ 10002 ] |
| Component/s | Server [ 13907 ] | |
| Fix Version/s | 11.0.1 [ 28548 ] | |
| Fix Version/s | 11.0 [ 28320 ] | |
| Assignee | Andrew Hutchings [ JIRAUSER52179 ] | Daniel Black [ danblack ] |
| Resolution | Fixed [ 1 ] | |
| Status | In Review [ 10002 ] | Closed [ 6 ] |
| Summary | deprecate log-slow-admin-statements, Better user experience with slow log filters | deprecate log-slow-admin-statements, Better user experience with slow log filters |
Start with https://github.com/MariaDB/server/pull/2357 deprecation.
Not sure I like the optimizer switch of putting a lot of variables into one variable. I've found it horridly hard to manipulate.
I think filter can be read as inclusive or exclusive. Other filter uses seem to be inclusive.