Details
-
Task
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
None
Description
It's a bit strange now that one cannot create an arbitrary history with arbitrary timestamps, unless one abuses replication, in which case one can. This is illogical.
A consistent approach could be a new command line option that controls who can set @@timestamp.
Something like --who-can-set-session-timestamp=NOBODY|REPLICATION|SUPER|ANYONE
(here "SUPER" implies "REPLICATION")
Can be set via command-line option only, read-only server variable.
perhaps REPLICATION is unnecessary, and NOBODY|SUPER|ANYONE is enough (if SUPER can abuse REPLICATION to change timestamp anyway).
And system versioning will use @@timestamp and not a separate shadow system time anymore.
Attachments
Issue Links
- blocks
-
MDEV-15380 Index for versioned table gets corrupt after partitioning and DELETE
-
- Closed
-
-
-
- Closed
-
Activity
| Field | Original Value | New Value |
|---|---|---|
| Priority | Major [ 3 ] | Critical [ 2 ] |
| Summary | option to control, who can set session @@timestamp | option to control who can set session @@timestamp |
| Description |
Something like {{--who-can-set-session-timestamp=NOBODY|REPLICATION|SUPER|ANYONE}}
Can be set via command-line option only, read-only server variable. perhaps REPLICATION is unnecessary, and NOBODY|SUPER|ANYONE is enough (if SUPER can abuse REPLICATION to change timestamp anyway). |
It's a bit strange now that one cannot create an arbitrary history with arbitrary timestamps, unless one abuses replication, in which case one can. This is illogical and inconsistent.
Something like {{--who-can-set-session-timestamp=NOBODY|REPLICATION|SUPER|ANYONE}} Can be set via command-line option only, read-only server variable. perhaps REPLICATION is unnecessary, and NOBODY|SUPER|ANYONE is enough (if SUPER can abuse REPLICATION to change timestamp anyway). |
| Description |
It's a bit strange now that one cannot create an arbitrary history with arbitrary timestamps, unless one abuses replication, in which case one can. This is illogical and inconsistent.
Something like {{--who-can-set-session-timestamp=NOBODY|REPLICATION|SUPER|ANYONE}} Can be set via command-line option only, read-only server variable. perhaps REPLICATION is unnecessary, and NOBODY|SUPER|ANYONE is enough (if SUPER can abuse REPLICATION to change timestamp anyway). |
It's a bit strange now that one cannot create an arbitrary history with arbitrary timestamps, unless one abuses replication, in which case one can. This is illogical.
A consistent approach could be a new command line option that controls who can set @@timestamp. Something like {{--who-can-set-session-timestamp=NOBODY|REPLICATION|SUPER|ANYONE}} Can be set via command-line option only, read-only server variable. perhaps REPLICATION is unnecessary, and NOBODY|SUPER|ANYONE is enough (if SUPER can abuse REPLICATION to change timestamp anyway). |
| Link |
This issue blocks |
| Description |
It's a bit strange now that one cannot create an arbitrary history with arbitrary timestamps, unless one abuses replication, in which case one can. This is illogical.
A consistent approach could be a new command line option that controls who can set @@timestamp. Something like {{--who-can-set-session-timestamp=NOBODY|REPLICATION|SUPER|ANYONE}} Can be set via command-line option only, read-only server variable. perhaps REPLICATION is unnecessary, and NOBODY|SUPER|ANYONE is enough (if SUPER can abuse REPLICATION to change timestamp anyway). |
It's a bit strange now that one cannot create an arbitrary history with arbitrary timestamps, unless one abuses replication, in which case one can. This is illogical.
A consistent approach could be a new command line option that controls who can set @@timestamp. Something like {{--who-can-set-session-timestamp=NOBODY|REPLICATION|SUPER|ANYONE}} (here "SUPER" implies "REPLICATION") Can be set via command-line option only, read-only server variable. perhaps REPLICATION is unnecessary, and NOBODY|SUPER|ANYONE is enough (if SUPER can abuse REPLICATION to change timestamp anyway). And system versioning will use @@timestamp and not a separate shadow system time anymore. |
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Status | In Progress [ 3 ] | Stalled [ 10000 ] |
| Fix Version/s | 10.3.7 [ 23005 ] | |
| Fix Version/s | 10.3 [ 22126 ] | |
| Resolution | Fixed [ 1 ] | |
| Status | Stalled [ 10000 ] | Closed [ 6 ] |
| Link |
This issue blocks |
| Workflow | MariaDB v3 [ 86637 ] | MariaDB v4 [ 133527 ] |