maria-developers team mailing list archive

[Ian Gilfillan <ian@xxxxxxxxxxx>]

In order to document this properly (and in response to 
https://jira.mariadb.org/browse/MDEV-13236) , I want to clarify a few 
things:

As I understand it:
* the variable is dynamic, so changes becomes effective immediately
* tables are created immediately whenever a transaction is seen from a 
specified engine (listed in the variable)
* the manual creation of the tables was an initial design suggestion, 
and there should be no need to ever create a table manually.

I don't have 10.3.1 running yet to test, but some questions:
* what happens if slave threads are not stopped before changing the 
variable? Just delay the creation of the table, or can something 
unpleasant happen from a table being created in the middle of something?
* what happens if a storage engine is later removed from the variable? 
If the table still exists, I presume the existence of the table takes 
priority and the table is still used - the variable is just used to 
check the existence of a table and create it if needs be, not determine 
its use?
* what benefit does the variable being empty (the default) provide? I 
saw the comment about the principle of least surprise, but in what way 
could it being populated and the tables existing be negative? In other 
words, why would one not simply recommend setting this immediately?
* If there is a benefit to it being empty (and therefore no multiple 
tables created), will there be a mechanism to remove a table beyond 
manually deleting?


On 03/07/2017 15:15, Kristian Nielsen wrote:
> I have now pushed the code to 10.3. It should appear in an upcoming MariaDB
> 10.3.1 release, IIUC.
>
> Following the discussion so far, the default for --gtid-pos-auto-engines is
> currently empty. It can be easily changed later (eg. to
> innodb,tokudb,rocksdb) simply by changing the default value in
> sql/mysqld.cc. The code will allow this default setting even if eg. tokudb
> or rocksdb is not enabled.
>
> (There might be a need to adjust a couple test cases that specially
> manipulates mysql.gtid_slave_pos in devious ways).
>
> Let me know in case of any problems or if there are comments/questions.
>
>   - Kristian.