#3046 Tracking + MySQL interactive_timeout yields error

[Björn Wiberg]

If the MySQL server has interactive_timeout set, e.g. to 60 seconds, and one exports a large table and has tracking enabled ($cfg['Servers'][$i]['tracking'] set to a non-empty value), one gets an error message after a little while:

"Fel

SQL-fråga: DokumentationÄndra Ändra

SELECT tracking_active
FROM `pmadb`.`pma_tracking`
WHERE `db_name` = 'linadb'
AND `table_name` = 'Uttag_Export'
ORDER BY version DESC

MySQL sa: Dokumentation
#2006 - MySQL server has gone away"

This is because the interactive timeout has kicked in and closed the connection and phpMyAdmin expects it to be open.
(Recall that the default timeout in MySQL is 5 minutes so depending on the size of the table anyone could experience this.)

It would be great if phpMyAdmin would re-open the connection if needed.

Or, as a work-around, if there were an option to send an SQL "preamble" to raise the interactive timeout prior to the query, e.g.:
SET SESSION interactive_timeout=600, SESSION wait_timeout=600;
...replacing 600 with ExecTimeLimit seconds from the configuration instead.

[Marc Delisle]

P.S. the default is 28800 (http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_interactive_timeout) which equals to 8 hours.

But we should look into this.

[Madhura Jayaratne]

According to http://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_interactive_timeout interactive_timeout is only applicable if the connection is started with CLIENT_INTERACTIVE option in mysql_real_connect(). However, in the current code base I can not seem to find any instance where the connection is started with CLIENT_INTERACTIVE option.

[Marc Delisle]

I suggest to close as we got no feedback. In particular we don't know which MySQL server version is running here.

[Ryan Murphy]

I get the "mysql server has gone away" error pretty often too. I don't know if it's for the same reason.

I noticed that the PHP code for the database (in the DBI folder) uses the @ sign to suppress errors for calls to the database. If we start responding to these errors, we could possibly handle these conditions more gracefully.