Always 0 for unexisting @@variables

[donhardman]

Bug Description:

There is an issue that blocks a task to be done: manticoresoftware/manticoresearch-buddy#388

When we do a select of any variable that does not exist at all, we return 0, which looks incorrect.

Let's return an error that this variable does not exist, because setting 0 as int for everything is not a good approach. So when we return an error here, we will be able to process such cases with Buddy.

mysql> SELECT @@tx_isolation_eahhahfefhehfehf;
+---------------------------------+
| @@tx_isolation_eahhahfefhehfehf |
+---------------------------------+
|                               0 |
+---------------------------------+
mysql>

Manticore Search Version:

Latest dev

Operating System Version:

Ubuntu

Have you tried the latest development version?

Yes

Internal Checklist:

^{To be completed by the assignee. Check off tasks that have been completed or are not applicable.}

• Implementation completed
• Tests developed
• Documentation updated
• Documentation reviewed
• Changelog updated

[tomatolog]

the related ticket is #1273

daemon always returns valid response for unknown @@variable.

Then the buddy present the response looks like

mysql -h 127.0.0.1 -P 9306 -e "SELECT @@tx_isolation_eahhahfefhehfehf;"
+---------------------------------+
| @@tx_isolation_eahhahfefhehfehf |
+---------------------------------+
|                               0 |
+---------------------------------+

then the buddy disable the response looks like

mysql -h 127.0.0.1 -P 9306 -e "SELECT @@tx_isolation_eahhahfefhehfehf;"
+---------------------------------+
| @@tx_isolation_eahhahfefhehfehf |
+---------------------------------+
| <empty>                         |
+---------------------------------+

The supported variables are: @@session.auto_increment_increment, @@character_set_client, @@character_set_connection, @@max_allowed_packet, @@version_comment, @@lower_case_table_names, @@session.last_insert_id, @@autocommit

However all other variables just returns 0 or <empty>.

In case we are going to change this behavior it worth to add new searchd.dummy_select_list_@@ option there user could enumerate all variables these should not fail or maybe provide instruction of how it could be fixed via Buddy.

For it should have format: variable name;variable type ( string \ long ); variable value

like

searchd.dummy_select_list_@@ = name1,string;yes
searchd.dummy_select_list_@@ = name15,long;15

That need as we do not have list of clients these depends on this behavior.

[sanikolaev]

Another related issue is https://gitlab.com/manticoresearch/dev/-/issues/3009 and the commit as the result of it - 8240fce05e . It doesn't explain why not NULL and why not an error.

[sanikolaev]

why not an error

Probably because in MySQL it's not considered an error either.

I suggest we do the following:

• Daemon: Instead of showing 0/<empty> in the daemon, let's return an error so it's routed to Buddy if the variable is unknown.
• Buddy: Let's show NULL by default, as in MySQL, and display other values when necessary.

Let's implement these changes in a branch, build the daemon and Buddy packages, and then:

• Test it with all mysqldump / mariadb-dump versions.
• Test the MySQL-related integrations we support, such as Grafana, Superset, UIs, etc.

[tomatolog]

I've just pushed the change into #3117

There I keep the current behavior for daemon runs without buddy and while buddy running daemon should fail query with any unknown sysvar and route these into buddy.

the new behavior

mysql -h 127.0.0.1 -P 9306 -e "SELECT @@autocomm;"
ERROR 1064 (42000) at line 1: unknown sysvar @@autocomm

mysql -h 127.0.0.1 -P 9306 -e "SELECT @autocomm;"
ERROR 1064 (42000) at line 1: P09: syntax error, unexpected TOK_USERVAR near ''

mysql -h 127.0.0.1 -P 9306 -e "SELECT autocomm;"
ERROR 1064 (42000) at line 1: unknown column: autocomm

the old behavior

mysql -h 127.0.0.1 -P 9306 -e "SELECT @@autocomm;"
+------------+
| @@autocomm |
+------------+
| <empty>    |
+------------+

mysql -h 127.0.0.1 -P 9306 -e "SELECT @autocomm;"
ERROR 1064 (42000) at line 1: P09: syntax error, unexpected TOK_USERVAR near ''

mysql -h 127.0.0.1 -P 9306 -e "SELECT autocomm;"
ERROR 1064 (42000) at line 1: unknown column: autocomm

need to check all failed cases at the PR and implement fixes at the buddy.

[sanikolaev]

@donhardman pls test the updated version or prepare a clear test plan for @PavelShilin89 .