[Phpmyadmin-devel] ready for 4.1.0-rc1 ?
marc at infomarc.info
Wed Nov 20 13:42:59 CET 2013
Martyn Dale a écrit :
> Personally I do not think it is advisable to move forward until certain
> issues have been addressed. I am talking about
> https://sourceforge.net/p/phpmyadmin/bugs/3944 and related bug reports.
> The alleged solution for 4.1 is requiring MySQL 5.5 as a minimum version.
> This is not going to solve the problems that people have reported when
> using the 4.x series with large systems, since while 5.5 is better than 5.1
> and below, a full directory scan can still be triggered by any number of
> combinations of variables as described here:
> I explained this in that bug report where i showed PMAs default usage of IS
> for the navigation on a *5.6* system (with innodb_stats_on_metadata
> switched off). While that was just a 2 second example, I have seen that get
> up to 60 seconds before query killers kick in. Reports of users on shared
> hosting accounts, where this kind of behavior can get users accounts
> terminated has also already been reported (
> https://sourceforge.net/p/phpmyadmin/bugs/3945, second page "Here is what
> one provider sent as a warning before *deleting my account*")
> If you remove the use of disableIS and related functionality, it will not
> solve any issues. Take the SCHEMATA queries for example for getting
> database lists, this still effectively does a full directory scan, as
> documented: http://dev.mysql.com/doc/refman/5.6/en/schemata-table.html
> In this case for example, switching to IS to avoid using the slow
> performing show databases is redundant since they basically do the same
> thing. As a basic example, take a directory, with tens of thousands of
> files, and attempt to do an ls in it, even unsorted (-U) it will take a
> long time, simply because traversal of the filesystem takes time. Requiring
> higher versions isnt going to miraculously speed up the iteration of
> On a similar note, when I referenced *innodb_stats_on_metadata *in earlier
> mentioned bug report, I was using it as an example of why relying on IS can
> be as bad, or worse than directly doing a show tables, since it can
> potentially end up doing additional work.
> I am pretty worried that modifying the variable was considered as a
> potential solution. The description of that very setting describes how it
> affects how the system handles IS queries. An administrator should be able
> to trust that installing something like PMA is not going to change any
> system variables that could otherwise affect the operation of the system
> Thank you for your consideration.
Thanks Martyn for your report. We'll discuss this issue before taking a
decision about 4.1.0-rc1.
Sadly, 4.1.0 will be released with some bugs in it, but we should avoid
regressions. So, in your opinion, is the current state of 4.1.0-beta
worse than 4.0.9, regarding this IS issue?
More information about the Developers