User tests: Successful: Unsuccessful:
Pull Request for Issue #41156 .
See also issues #17580 and #39479 , discussion #42198 and support forum thread https://forum.joomla.org/viewtopic.php?f=811&t=995872 .
Requires joomla-framework/database#292 .
This pull request (PR) adds a new option to the "Database" section of Global Configuration which allows to set the "sql_big_selects" session variable to on or off or leave it untouched, which is the default.
So when people run into the 1104 The SELECT would examine more than MAX_JOIN_SIZE rows ...
error with their database server, they can fix that by switching the new option to "Yes".
When the default value of the option is used, which is also the case after a CMS update to a new version which includes this PR here, then nothing is done, so there is no unnecessary SQL statement issues with each connection in that case.
The issue has been reported more frequently in recent times, so I think we should fix it as a bug fix in 4.4-dev and merge it up later.
I have made the additional feature PR #42559 for the 5.1-dev branch to show the values of the "sql_big_selects" and "max_join_size" variables in the System Information on MySQL or MariaDB databases.
In case if the framework PR #joomla-framework/database#292 is not accepted for some reason, I have created PR #42558 as an alternative to this one here, which does the same but doesn't require a change in the database framework. That alternative is not nice, but it works the same as this one here.
This PR is only relevant for MySQL or MariaDB databases, not for PostgreSQL.
When having tested with success, please leave a comment about that in the framework PR joomla-framework/database#292 because a successful test for this PR here will also mean a successful test of that PR.
For some test steps which change the global "sql_big_select" variable it needs to have administrator privileges for the database. E.g. on a local MySQL you have to connect with user "root" when using e.g. phpMyAdmin. That means that these test steps can't be executed in a shared hosting environment.
use
statements in the PHP code at the top, e.g. if Cassiopeia is used file "templates/cassiopeia/index.php" at line 20, to show the current value of the "sql_big_select" session variable:echo 'TEST: ' . Factory::getDbo()->setQuery('SELECT @@sql_big_selects;')->loadResult() . '<br>';
SELECT @@GLOBAL.sql_big_selects, @@SESSION.sql_big_selects;
SET GLOBAL sql_big_selects=1;
There is no way to change the value of the "sql_big_select" session variable.
A new list select option "Allow large queries" is available at the end of the "Database" section in the "Server" tab of Global Configuration ($dbsqlbigselects
in configuration.php
).
The option is only shown when the selected database type is "MySQLi" or "MySQL (PDO)". When "PostgreSQL (PDO)" is selected, the new option is hidden.
The value of that option is the default value "No change (server controlled)" after a new installation or an update.
When the new option has that default value, the value of the "sql_big_selects" session variable is not changed by the CMS, and no additional SQL statement is performed when connecting to the database.
When the new option has value "No", the value of the "sql_big_selects" session variable is set to 0 when connecting to the database.
When the new option has value "Yes", the value of the "sql_big_selects" session variable is set to 1 when connecting to the database. This will prevent the SQL error 1104 The SELECT would examine more than MAX_JOIN_SIZE rows ...
.
Please select:
Documentation link for docs.joomla.org: https://docs.joomla.org/Help4.x:Site_Global_Configuration https://docs.joomla.org/Help4.x:Site_Global_Configuration_Server
No documentation changes for docs.joomla.org needed
Pull Request link for manual.joomla.org:
No documentation changes for manual.joomla.org needed
A description of the new "Allow large queries" parameter should be added to the end of sub-section "database" of the "Server" section on https://docs.joomla.org/Help4.x:Site_Global_Configuration / https://help.joomla.org/proxy?keyref=Help44:Site_Global_Configuration&lang=en .
Suggested text:
The screenshot on https://docs.joomla.org/Help4.x:Site_Global_Configuration_Server needs to be updated so it shows the new option.
Status | New | ⇒ | Pending |
Category | ⇒ | Administration com_config Language & Strings Installation Libraries |
Labels |
Added:
Language Change
bug
PR-4.4-dev
|
@wilsonge P.S. Unfortunately I wasn’t able to find the critical query up to now. I could not reproduce the issue with the small max_join_size and sql_big_queries disabled like it was reported in the support forum. It seems to need certain starting conditions. Possibly a bunch of 3rd party extensions or whatever.
Title |
|
@wilsonge Meanwhile we got a stack trace in issue #41156 , and it's the big query for getting the IDs of all core extensions. But I don't get the issue on MySQL, so either it happens only with MariaDB 10.6, or the "extension" index is missing for some reason on the site with the issue so the query results in a full table scan.
@wilsonge PR is #42576 . It is draft because I need to complete the testing instructions. As soon as ready for tests I will post here and close this issue. But interested readers may already have a look on it. It's still worth a question if this PR here could make sense for the case that the error happens also with other queries, e.g. from 3rd party extensions.
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2023-12-30 12:21:09 |
Closed_By | ⇒ | richard67 |
Sorry with holidays and stuff in December didn't get time to look at this - but I'm much happier with fixing the query as proposed (yes I know it needs a follow up) than this PR. So major +1 on the way forward (closing this and merging that one + the fix)
Status | Closed | ⇒ | New |
Closed_Date | 2023-12-30 12:21:09 | ⇒ | |
Closed_By | richard67 | ⇒ |
Status | New | ⇒ | Pending |
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2024-01-12 14:15:15 |
Closed_By | ⇒ | wilsonge |
I think rather than just blasting the server for all queries we need to think about a more targeted approach. Judging by the page and the fact this happens more frequently it would be my guess that this is some sort of query from the extension compatibility information? We don't want the database to limit access to the rest of the site when the Update Joomla page is shown because the db is throttled with the other query (and that's a genuine thing - a while back on the main downloads site loading the ARS dashboard gave this issue because of the number of downloads).
We a) need to investigate what query is failing when we load that page and optimise it and b) if we really really need this (and I'd hope we don't for anything in core) then we need to consider allowing this on a page specific way I think rather than globally hiding the issue for all future queries.