Yes, it's a special code that prohibits any users in mysql.user table to have SUPER privilege. We keep all users that need to have SUPER in a separate table with the same structure as mysql.user.
I hope I'll be able to give you a link to this code by the end of this week.

Now that our code is opensourced you can look at the special code I was talking about if you wish. It's here https://code.google.com/p/google-mysql/source/list?name=mariadb-10.0.12%2F05-isolation, see the commit "Add parameter for blocking certain user privileges" which depends on the previous one "Add special system users support".

Thanks Pavel Ivanov I'll definitely look at integrating that in some way, especially if it gets merged and alternately using similar checks in a #ifdef xxx to reduce your maintenance.

For the moment I'm waiting on a little more of a conceptual review and perhaps a quick check if I've don't anything dumb in sql_yacc.yy.

I think Serg wanted to reply to this, but I guess he has been busy with other
stuff so far (as have I - I apologise for the delay in replying to your
several patches, but things are too busy lately).

Serg and I discussed this briefly, and we both felt that this (adding another
priviliege and new user table columns) does not seem the best way to do
things?

For one, it seems too ad-hoc - there are probably other settings that could be
useful for non-superuser access in some cases, should they also have separate
privileges and columns?

And besides - this method of new privilege does not seem to be the most useful
way for the DBA? One thing that could be really useful would be the ability to
make the domain_id be a hash function of the currently selected database, to
simulate mysql per-database parallelism. Or a hash function of the currently
selected user. Eg. pseudo-code:

SET GLOBAL gtid_domain_id = HASH(CURRENT DATABASE) MOD 10;

or something like that - but the exact syntax needs some more thought to be
flexible and consistent. Maybe just a GLOBAL gtid_domain_id_function variable,
which contains the name of a stored function that sets the value?

Or what if there was a general mechanism to set --init-connect, but on a
per-user basis? Then this could be used to set the domain id for a as desired,
but also be used to control any other setting.

Do you think it is really useful to set a range of allowed domain ids for a
non-superuser? It seems to me that as soon as a user has the ability to set
two different domain ids, that user has the ability to break replication
anyway, by creating conflicting transactions with different domain ids. So not
sure how restricting the range would help in practice.

It also seems that a stored procedure with SQL SECURITY DEFINER could have a
role here? The superuser could define a stored procedure and give a
non-privileged user execute access. Such a procedure could provide the ability
to change the domain_id, with a high degree of flexibility?

--init-connect, but on a per-user basis? Then this could be used to set the domain id for a as desired,

but also be used to control any other setting.

The init-connect method is what i used in combination with a user lookup in the blog above and this could also do the same as gtid_domain_id_function.

Do you think it is really useful to set a range of allowed domain ids for a non-superuser? It seems to me that as soon as a user has the ability to set two different domain ids, that user has the ability to break replication anyway, by creating conflicting transactions with different domain ids. So not sure how restricting the range would help in practice.

Yes is only really useful if this is resolved such that breaks only stop the replication of conflicting domains and giving a user the ability to resolve this which I think is about two features beyond what really needs to be considered now.

It also seems that a stored procedure with SQL SECURITY DEFINER...

yes that was done in the blog above too.

I was aiming at a generic interface that allows a Drupal application for instance to keep disparate sections of their code (cache, vs entities vs users vs event logs) to have a different domain-id and hence explicitly paralleling them. Something that is clear and obvious and could be incorporated into the Drupal distribution code as a pseudo data paralleling interface.

So I'll experiment some more with stored procedures, multi source replication (each with domain id filters and the same master) to avoid total replication faults (concept flawed?) maybe. And I'll see how useful that is. Stats on in-order parallel replication will see if there is much to be improved by going explicit.

MDEV-6594 Use separate domain_id for Galera transactions kind of needs to be considered.