https://opennet.ru/openforum/vsluhforumID3/69834.html Вышел (http://permalink.gmane.org/gmane.comp.db.mysql.announce/566) релиз комьюнити сборки MySQL 5.1.50 (http://dev.mysql.com/downloads/), содержащей исправление 24 ошибок, 4 из которых приводили к краху рабочего процесса: <br><br><br>- при переименовании таблицы при наличии незавершенных транзакций; <br>- при запуске в фазе восстановления после некорректного завершения, которое произошло в момент записи BLOB-данных в InnoDB-таблицу, созданную в режиме ROW_FORMAT=REDUNDANT или ROW_FORMAT=COMPACT;<br>- при попытке передачи в предварительно подготовленный запрос (prepared statement) параметра с типом отличным от TEXT и BLOB, при использовании функции mysql_stmt_send_long_data() или выражения COM_STMT_SEND_LONG_DATA;<br>- в момент завершения работы, при запуске сервера с параметром "--innodb-use-system-malloc=0".<br><br><br><br><br><br><br><br>Отдельно можно отметить устранение проблемы с маппингом памяти при выполнении MERGE-операций на платформе FreeBSD. Поставляемый в комплекте с MySQL дополнительный InnoDB Plugin обновлен до версии https://opennet.ru/openforum/vsluhforumID3/69834.html#18 Sat, 21 Aug 2010 13:31:11 GMT &gt;Не забыл, там походу был какой-то секюрити багфикс который и сломал это <br>&gt;всё. Т.е. теперь <br>&gt;GRANT ALL PRIVILEGES ON db.* TO не катит, а именно db.* <br><br>хм. ну попробуйте перед обновлением снять дамп, а потом его загрузить в новую версию<br> https://opennet.ru/openforum/vsluhforumID3/69834.html#17 Sat, 21 Aug 2010 08:08:20 GMT Не забыл, там походу был какой-то секюрити багфикс который и сломал это всё. Т.е. теперь <br>GRANT ALL PRIVILEGES ON db.* TO не катит, а именно db.*<br> https://opennet.ru/openforum/vsluhforumID3/69834.html#16 Fri, 20 Aug 2010 16:09:17 GMT &gt;чёто, с учётом всего вышесказанного, не верится. <br><br>Есть аргументы или ты это просто так сказал?<br> https://opennet.ru/openforum/vsluhforumID3/69834.html#15 Fri, 20 Aug 2010 16:08:10 GMT Вот и я про то же. Написано только для венды, но в реальности то же самое для сборок под RHAS4 и 5 версии.<br> https://opennet.ru/openforum/vsluhforumID3/69834.html#14 Fri, 20 Aug 2010 14:27:51 GMT чёто, с учётом всего вышесказанного, не верится.<br> https://opennet.ru/openforum/vsluhforumID3/69834.html#13 Fri, 20 Aug 2010 14:26:46 GMT &gt;The maximum permissible setting for key_buffer_size is 4GB on 32-bit platforms. As of MySQL 5.0.52, values larger than 4GB are permitted for 64-bit platforms (except 64-bit Windows, for which large values are truncated to 4GB with a warning).<br><br>т.е. в винде (любой) больше 4GB быть не может.<br>но по факту например в 32-bit XP - до 2 gb.<br> https://opennet.ru/openforum/vsluhforumID3/69834.html#12 Fri, 20 Aug 2010 11:37:29 GMT mysql_upgrade не забыли выполнить после обновления?<br> https://opennet.ru/openforum/vsluhforumID3/69834.html#11 Fri, 20 Aug 2010 11:27:24 GMT У меня начиная с версии 5.1.47 начались проблемы с правами на таблицы, т.е. юзер заведенный в мускуле с полными правами на базу и все ее таблицы не может даже select сделать, откатываюсь на 5.1.46 - всё работает. ппц<br> https://opennet.ru/openforum/vsluhforumID3/69834.html#10 Fri, 20 Aug 2010 10:47:27 GMT &gt;ребята, ребята кэш индекса myisam не может быть больше 4 Гб на <br>&gt;любой архитектуре <br>&gt;пруф http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html#sysvar_key_buffer_size <br><br>Не увидел где там 4Г максимально для ЛЮБОЙ архитектуры.<br>По факту размер усекается с предупреждением до 4 Г.<br>ЕМНИП у них была проблема и они нашли выход, объявив баг фичей.<br>