maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

Martin Kaluznik <martin.kaluznik@xxxxxxxxx> writes:

> ...). 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.