The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Корректирующий релиз MySQL Community Server 5.1.50

20.08.2010 10:59

Вышел релиз комьюнити сборки MySQL 5.1.50, содержащей исправление 24 ошибок, 4 из которых приводили к краху рабочего процесса:

  • при переименовании таблицы при наличии незавершенных транзакций;
  • при запуске в фазе восстановления после некорректного завершения, которое произошло в момент записи BLOB-данных в InnoDB-таблицу, созданную в режиме ROW_FORMAT=REDUNDANT или ROW_FORMAT=COMPACT;
  • при попытке передачи в предварительно подготовленный запрос (prepared statement) параметра с типом отличным от TEXT и BLOB, при использовании функции mysql_stmt_send_long_data() или выражения COM_STMT_SEND_LONG_DATA;
  • в момент завершения работы, при запуске сервера с параметром "--innodb-use-system-malloc=0".

Отдельно можно отметить устранение проблемы с маппингом памяти при выполнении MERGE-операций на платформе FreeBSD. Поставляемый в комплекте с MySQL дополнительный InnoDB Plugin обновлен до версии 1.0.11, относящейся к категории пригодных к промышленной эксплуатации.

  1. Главная ссылка к новости (http://permalink.gmane.org/gma...)
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/27677-mysql
Ключевые слова: mysql
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (17) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, igorsia (?), 12:20, 20/08/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Оно теперь умеет использовать больше 4Г памяти для кэша индексов?
     
     
  • 2.2, Vaso Petrovich (?), 12:42, 20/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Оно теперь умеет использовать больше 4Г памяти для кэша индексов?

    А вы где это пробовали? ОС, крайне интересует...

     
     
  • 3.4, фноним (?), 13:28, 20/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    конечно он это в винде делал, так там и не такие проблемы будут
     
  • 3.5, Michael (??), 13:40, 20/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    ребята, ребята кэш индекса myisam не может быть больше 4 Гб на любой архитектуре
    пруф http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html#sysvar_ke
     
     
  • 4.6, Vaso Petrovich (?), 14:04, 20/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >ребята, ребята кэш индекса myisam не может быть больше 4 Гб на
    >любой архитектуре
    >пруф http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html#sysvar_ke

    Дело в том, что на винде, он больше 2 гигов, вообще быть не может... ОС такая...

     
     
  • 5.7, Michael (??), 14:15, 20/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >>ребята, ребята кэш индекса myisam не может быть больше 4 Гб на
    >>любой архитектуре
    >>пруф http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html#sysvar_ke
    >
    >Дело в том, что на винде

    ясн )) вопрос снят )))

     
  • 4.10, igorsia (?), 14:47, 20/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >ребята, ребята кэш индекса myisam не может быть больше 4 Гб на
    >любой архитектуре
    >пруф http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html#sysvar_ke

    Не увидел где там 4Г максимально для ЛЮБОЙ архитектуры.
    По факту размер усекается с предупреждением до 4 Г.
    ЕМНИП у них была проблема и они нашли выход, объявив баг фичей.

     
     
  • 5.13, аноним (?), 18:26, 20/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >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).

    т.е. в винде (любой) больше 4GB быть не может.
    но по факту например в 32-bit XP - до 2 gb.

     
     
  • 6.15, igorsia (?), 20:08, 20/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Вот и я про то же. Написано только для венды, но в реальности то же самое для сборок под RHAS4 и 5 версии.
     
  • 3.9, igorsia (?), 14:38, 20/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    CentOS 5.3_64
     
     
  • 4.14, аноним (?), 18:27, 20/08/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    чёто, с учётом всего вышесказанного, не верится.
     
     
  • 5.16, igorsia (?), 20:09, 20/08/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >чёто, с учётом всего вышесказанного, не верится.

    Есть аргументы или ты это просто так сказал?

     

  • 1.3, Аноним (-), 13:11, 20/08/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Корректирующие релизы стали выходить чаще, вроде)
     
  • 1.11, Аноним (-), 15:27, 20/08/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    У меня начиная с версии 5.1.47 начались проблемы с правами на таблицы, т.е. юзер заведенный в мускуле с полными правами на базу и все ее таблицы не может даже select сделать, откатываюсь на 5.1.46 - всё работает. ппц
     
  • 1.12, Michael (??), 15:37, 20/08/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    mysql_upgrade не забыли выполнить после обновления?
     
     
  • 2.17, Аноним (-), 12:08, 21/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Не забыл, там походу был какой-то секюрити багфикс который и сломал это всё. Т.е. теперь
    GRANT ALL PRIVILEGES ON db.* TO не катит, а именно db.*
     
     
  • 3.18, Michael (??), 17:31, 21/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Не забыл, там походу был какой-то секюрити багфикс который и сломал это
    >всё. Т.е. теперь
    >GRANT ALL PRIVILEGES ON db.* TO не катит, а именно db.*

    хм. ну попробуйте перед обновлением снять дамп, а потом его загрузить в новую версию

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру