A somewhat random example which generates error code 1046:
SET GLOBAL init_slave='CREATE VIEW v1 SELECT f1()'; |
CHANGE MASTER TO master_host='a'; |
START SLAVE SQL_THREAD;
|
Changing the query to SELECT 1 does not generate an error, even though there is no way it can be executed on the slave (master/slave not configured) 
A somewhat random example which generates error code 1064:
SET GLOBAL init_slave='a'; |
CHANGE MASTER TO master_host='a'; |
START SLAVE SQL_THREAD;
|
Apparently, in protocol design, one of the teachings is to abstract things, i.e. it does not actually matter if a packet was lost or if it was corrupted: just drop any corrupted packets and let the retransmission logic take care of it, which is how TCP/IP works. w/ Thanks to marko for the insightful points/discussion.
Thinking about this again, it would be good if we can achieve both ends (as noted towards the end of the original description): have a single error code for when init_slave cannot be executed, yet have some form of reason provided within the error message, i.e. something like (9999 is a fictive error code for ER_INIT_SLAVE_ERROR):
MariaDB error code 9999 (ER_INIT_SLAVE_ERROR): Can't execute init_slave query due to MariaDB error code ...some other code...
|
What does it mean "all these errors being filtered"? Where are they being filtered, and why?
What is an example exact error message (from command line/ START SLAVE as well as slave error log) when this occurs?
This error seems it would be very specific to (1) a START SLAVE run while (2) --init-slave being in effect. Filtering events in this specific case doesn't seem like something that should affect any other testing. And besides, replacing all errors with a generic 9999 error which is then filtered, will have the exact same effect, it seems?
It sounds like the real problem here is some filtering in some test tool that is insufficiently precise to the particular circumstances (1) and (2)? If so, the test tool should probably be fixed.
On the other hand, I agree the best behaviour would be if the error messages describes both that there was an error running the --init-slave query string, as well as the actual error that occurred.
We do have the ability to present multiple error codes, at least with SHOW WARNINGS.
> I agree the best behaviour would be if the error messages describes both that there was an error running the --init-slave query string, as well as the actual error that occurred
Me 2.
What do you see about reusing Slave_SQL_Running_State to start keeping an error status, which would mention
an execution phase of an error occurred; currently in an error case the field is empty?
I agree that moving to a generic error is not the best solution. The "best behaviour would be if the error messages describes both that there was an error running the --init-slave query string, as well as the actual error that occurred" indeed sounds like the best way forward, and makes it much clearer for users and testers what happened, without having to check error codes. Let's proceed that way, if feasible.
Actually Slave_SQL_Running_State 's state transitions reflect the sql thread's THD statuses. So it can't help immediately. But then I turn to think if Show-slave-status indeed is missing something like
Last_SQL_Error_state which would be a copy of Slave_SQL_Running_State at an error time.
As per the discussion,
for this part "there was an error running the --init-slave query string" there is error defined
```
rli->report(ERROR_LEVEL, thd->get_stmt_da()->sql_errno(), NULL,
"Slave SQL thread aborted. Can't execute init_slave query");
goto err;
```
and only need to add this part "the actual error that occurred" right?
ultravoilet26 Thank you. If feasible, yes.