On 21.07.22 10:37, Reindl Harald wrote:
10.2.x to 10.2.y and mysql_upgrade crashing
can you point me at a related bug report for that?
but now developers pretend they even *really test* jumps from 10.2 to 10.6 - are you guys kidding me?
I'm not a developer, or at least that's not my job description at MariaDB Corp., but no, I'm not trying to kid you.
(which now stops with the message "There is no need to run mysql_upgrade again")
While there have been a few cases where the system table schema changed within a major release series (in all cases I remember by simply extending the size of some VARCHAR) the plan is to never have that again within in a major release. With new major releases happening more frequently these days (which can be considered arguably by itself, but that is another story) any such change can now more easily wait on the next major release. And so mysql_upgrade on a minor release does not actually have to do anything anyway. The new logic just takes a shortcut by checking whether the current major release number differs from what is stored as last known version, and when seeing the same number it just terminates right away (unless when started with --force) instead of spending time on individual checks that will end up in "nothing to do" anyway. The main problem with this change that I see is with the wording of the message printed in that case, and if you check the related MDEV-28209 you'll see that it was reported by me. The other (long standing) issue with the mysql_upgrade version check is that it relies on information stored in a flat file, and not in the database itself, so e.g. in case of a "mysql" system schema restored from a mysqldump taken from an older instance mysql_upgrade may report that no action is needed based on wrong information. But that's a totally different story, and if anyone wants to chime in on the related MDEV-23008 (also reported by me) I'd be happy to see that. -- Hartmut Holzgraefe, Principal Support Engineer (EMEA) MariaDB Corporation | http://www.mariadb.com/