Martin Kaluznik
...). What are general guidelines for introduction of new error codes? Is there anything else I need to do except adding it to /sql/share/errmsg-utf8.txt ?
Generally, that is all that is required. You need to add it at the end, so that existing error numbers do not change.
I would create only one new error code - ER_PROVISIONING_FAILED - and place specific messages inside formatted text - same way as ER_MASTER_FATAL_ERROR_READING_BINLOG works.
Should be fine.
It doesn't go well with translations, but... you can decide.
Generally, new errors are added only in English, so that should be fine.
Maybe create different error codes at least for errors, where we are expecting user to fix them - table without index, statement mode.
That is fine as well, I think.
Also, how to tell slave from master that provisioning finished? Is
Hm, right, that is an interesting question. I wonder what should happen when the provisioning completes. I think the slave threads should be stopped. User must explicitly run START SLAVE afterwards. That also avoids any worries about somehow switching the internal state of replication threads from "provisioning" mode to "normal" mode. I wonder if this could be done simply by completing the COM_BINLOG_DUMP client command with an "ok" return? I think normally COM_BINLOG_DUMP never completes, it either fails with an error, or runs indefinitely. So that seems the most natural way to do it, if it is possible.
introduction of new error code ER_PROVISIONING_DONE acceptable solution? The error itself would never produce error message in logs.
If simply returning ok status is not easy to do, I think this is an acceptable solution as well.
Alternatively I can reuse / create similar event to Stop_log_event,
Right, that is an option too. We just have to be careful not to accidentally send such an event that happens to be in the binlog already. Stop_log_event could be acceptable, since it would not be generated in the middle of provisioning. Or even a query event containing a specific string (like an SQL comment) - since we can never send user-made Query events during provisioning. It is also possible to add a new event, we have a range of event codes used for MariaDB-specific events to not conflict with events introduced in MySQL.
note - provisioning is completed after SQL thread processes whole relay log, not when IO thread receives this event, so even reuse would require additional code.
Yes, good point. This would suggest that using a special event is the easiest approach? Or alternatively, the IO thread could just set a shared variable to the end of the relay log to tell the SQL thread when provisioning is done. Since this provisioning mode is special, and what happens is not exposed to any other clients, we should have some freedom in what we do, so it is mostly about finding something that makes the implementation simple and natural.
And side question, is there any log event other than Query_log_event which can produce ddl statement?
It seems there is not. I wrote an overview of event types some time ago, maybe it will be interesting to you: http://kristiannielsen.livejournal.com/13253.html http://kristiannielsen.livejournal.com/13382.html There are a number of events that implement LOAD DATA INFILE, while they are technically not DDL, they might require same treatment (eg. provisioning must fail if they occur). - Kristian.