Sergei Golubchik
added a comment - - edited or may be
CREATE TRIGGER ... AFTER STARTUP ...
CREATE TRIGGER ... BEFORE SHUTDOWN ...
at the same time we could also add
CREATE TRIGGER ... ON SCHEDULE ...
just for consistency.
serg
Let me correct the term to go further.
My term the 'Trigger' means literally 'triggering' action not the TRIGGER on behalf of table.
For 'Startup' or 'Shutdown' is that to execute any of procedure, function, or even normal queries that
the normal EVENT can do.
So the implementation should not be part of the TRIGGER. but part of EVENT.
Is that reasonable for all of us? That is why I used the word 'event scheduler' in the very first context.
Mitchell Lee
added a comment - - edited serg
Let me correct the term to go further.
My term the 'Trigger' means literally 'triggering' action not the TRIGGER on behalf of table.
For 'Startup' or 'Shutdown' is that to execute any of procedure, function, or even normal queries that
the normal EVENT can do.
So the implementation should not be part of the TRIGGER. but part of EVENT.
Is that reasonable for all of us? That is why I used the word 'event scheduler' in the very first context.
yes, that's what I mean too. A generalized "trigger" which is triggered by specific event, be it INSERT/UPDATE/DELETE in a table, a specific point in time, a startup or shutdown of the server, or whatever. I'm sure there will be more requests in the future, e.g. a login or logout of the user, start or stop of replication, etc.
It'd help to understand the feature better if you could provide examples of actions you want to do on startup or on shutdown. You surely already have something in mind.
Sergei Golubchik
added a comment - - edited yes, that's what I mean too. A generalized "trigger" which is triggered by specific event, be it INSERT/UPDATE/DELETE in a table, a specific point in time, a startup or shutdown of the server, or whatever. I'm sure there will be more requests in the future, e.g. a login or logout of the user, start or stop of replication, etc.
It'd help to understand the feature better if you could provide examples of actions you want to do on startup or on shutdown. You surely already have something in mind.
For startup : clean temp table(not by create temporary table but normal one for temporary data purpose), create preset daily data insertion for query boost up
For shutdown : rebuild table (by query 'OPTIMIZE NO_WRITE_TO_BINLOG TABLE tt_a') and batch job before end up.
A need to consider some points are:
What if got an error or warning when do something while shutdown event, how to handle it? stop shutting down or?
On windows environment, usually the db gets shutdown signal when OS shutting down. What if the shutdown 'OPTIMIZE' script take....an hour or more, can the MariaDB hold the shutting down until it finishes?
Mitchell Lee
added a comment - - edited Use cases should be
For startup : clean temp table(not by create temporary table but normal one for temporary data purpose), create preset daily data insertion for query boost up
For shutdown : rebuild table (by query 'OPTIMIZE NO_WRITE_TO_BINLOG TABLE tt_a') and batch job before end up.
A need to consider some points are:
What if got an error or warning when do something while shutdown event, how to handle it? stop shutting down or?
On windows environment, usually the db gets shutdown signal when OS shutting down. What if the shutdown 'OPTIMIZE' script take....an hour or more, can the MariaDB hold the shutting down until it finishes?
MariaDB can already have a very slow shutdown (e.g. flushing a big InnoDB buffer pool, if it's enabled) and it can have errors during shutdown. These new cases won't be any conceptually different.
Depends on how OS is configured, it can forcefully kill the slow process or it can wait
Sergei Golubchik
added a comment - MariaDB can already have a very slow shutdown (e.g. flushing a big InnoDB buffer pool, if it's enabled) and it can have errors during shutdown. These new cases won't be any conceptually different.
Depends on how OS is configured, it can forcefully kill the slow process or it can wait
Let me correct the term to go further.
My term the 'Trigger' means literally 'triggering' action not the TRIGGER on behalf of table.
For 'Startup' or 'Shutdown' is that to execute any of procedure, function, or even normal queries that
the normal EVENT can do.
So the implementation should not be part of the TRIGGER. but part of EVENT.
Is that reasonable for all of us? That is why I used the word 'event scheduler' in the very first context.
------
Don't keep get confuse with the word 'trigger' what we are talking about is the EVENT which already exsist. but triggerring time setting enhancement for startup/shutdown.
Mitchell Lee
added a comment - @Sergei Golubchik,
Let me correct the term to go further.
My term the 'Trigger' means literally 'triggering' action not the TRIGGER on behalf of table.
For 'Startup' or 'Shutdown' is that to execute any of procedure, function, or even normal queries that
the normal EVENT can do.
So the implementation should not be part of the TRIGGER. but part of EVENT.
Is that reasonable for all of us? That is why I used the word 'event scheduler' in the very first context.
------
Don't keep get confuse with the word 'trigger' what we are talking about is the EVENT which already exsist. but triggerring time setting enhancement for startup/shutdown.
I think the word "trigger" is just a general way of describing the commands.
The end result will be that you will be able to execute any procedure, function, query, etc. after the server startup and before the server shutdown automatically.
New Feature
Critical
MDEV-30643 Feature request - Allow concat function at a specific statment
or may be
at the same time we could also add
just for consistency.