Меню
Что нового?

MySQL 4.0.12 released

dak

Guest
Ну наконец, то!!! Свершилось! :)
Вопрос теперь в том, когда наши провайдеры обновят production MySQL с 3 версии на 4-ю! Вроде как теперь можно, не опасно, а то отмазывались раньше, что мол gamma ненадежно... :)
Есть большое желание узнать как быстро отреагируют на это московские хостеры, пусть народ запостит мессагу, когда у него на хостинге MySQL обновят до 4 версии!
 

si

Administrator
Код: 
Hi,

MySQL 4.0.12, a new version of the popular Open Source Database, has been
released. It is now available in source and binary form for a number of
platforms from our download pages at [url]http://www.mysql.com/downloads/[/url] and
mirror sites.

Note that not all mirror sites may be up to date at this point of time -
if you can't find this version on some mirror, please try again later or
choose another download site.

Starting with MySQL 4.0.12, MySQL 4.0 is now labelled as "production"
instead of "gamma".

Users of MySQL 3.23 are encouraged to upgrade, since MySQL 3.23 will now
be phased out slowly. It will still be supported, but only critical bug
and security fixes will be applied to the 3.23 code base.

News from the ChangeLog:

Functionality added or changed:

 * `mysqld' no longer reads options from world-writeable config files.

 * Integer values between 9223372036854775807 and 9999999999999999999
   are now regarded as unsigned longlongs, not as floats. This makes
   these values work similar to values between 10000000000000000000
   and 18446744073709551615.

 * `SHOW PROCESSLIST' will now include the client TCP port after the
   hostname to make it easier to know from which client the request
   originated.

Bugs fixed:

 * Fixed `mysqld' crash on extremely small values of `sort_buffer'
   variable.

 * `INSERT INTO u SELECT ... FROM t' was written too late to the
   binary log if t was very frequently updated during the execution of
   this query. This could cause a problem with `mysqlbinlog' or
   replication. The master must be upgraded, not the slave. (bug #136).

 * Fixed checking of random part of `WHERE' clause (bug #142).

 * Fixed a bug with `multi-table updates' with `InnoDB' tables. This
   bug occured as, in many cases, `InnoDB' tables can not be updated
   "on the fly", but offsets to the records have to be stored in a
   temporary table.

 * Added missing file `mysql_secure_installation' to the `server' RPM
   subpackage (bug #141).

 * Fixed MySQL (and `myisamchk') crash on artificially corrupted
   `.MYI' files.

 * Don't allow `BACKUP TABLE' to overwrite existing files.

 * Fixed a bug with multi-table `UPDATE's when user had all privileges
   on the database where tables are located and there were any
   entries in `tables_priv' table, i.e. `grant_option' was true.

 * Fixed a bug that allowed a user with table or column grants on
   some table, `TRUNCATE' any table in the same database.

 * Fixed deadlock when doing `LOCK TABLE' followed by `DROP TABLE' in
   the same thread.  In this case one could still kill the thread
   with `KILL'.

 * `LOAD DATA LOCAL INFILE' was not properly written to the binary
   log (hence not properly replicated). (bug #82).

 * `RAND()' entries were not read correctly by `mysqlbinlog' from the
   binary log which caused problems when restoring a table that was
   inserted with `RAND()'. `INSERT INTO t1 VALUES(RAND())'. In
   replication this worked ok.

 * `SET SQL_LOG_BIN=0' was ignored for `INSERT DELAYED' queries.
   (bug #104).

 * `SHOW SLAVE STATUS' reported too old positions (columns
   `Relay_Master_Log_File' and `Exec_master_log_pos') for the last
   executed statement from the master, if this statement was the
   `COMMIT' of a transaction. The master must be upgraded for that,
   not the slave. (bug #52).

 * `LOAD DATA INFILE' was not replicated by the slave if
   `replicate_*_table' was set on the slave. (bug #86).

 * After `RESET SLAVE', the coordinates displayed by `SHOW SLAVE
   STATUS' looked un-reset (though they were, but only internally).
   (bug #70).

 * Fixed query cache invalidation on `LOAD DATA'.

 * Fixed memory leak on `ANALYZE' procedure with error.

 * Fixed a bug in handling `CHAR(0)' columns that could cause wrong
   results from the query.

 * Fixed rare bug with wrong initialization of `AUTO_INCREMENT'
   column, as a secondary column in a multi-column key (*note
   `AUTO_INCREMENT' on secondary column in a multi-column key:
   example-AUTO_INCREMENT.), when data was inserted with `INSERT ...
   SELECT' or `LOAD DATA' into an empty table.

 * On windows, `STOP SLAVE' didn't stop the slave until the slave got
   one new command from the master (this bug has been fixed for MySQL
   4.0.11 by releasing updated 4.0.11a windows packages, which
   include this individual fix on top of the 4.0.11 sources).
         (bug #69).

 * Fixed a crash when no database was selected and `LOAD DATA' command
   was issued with full table name specified, including database
   prefix.

 * Fixed a crash when shutting down replication on some platforms
   (e.g. Mac OS X).

 * Fixed a portability bug with `pthread_attr_getstacksize' on
   HP-UX 10.20 (Patch was also included in 4.0.11a sources).

 * Fixed the `bigint' test to not fail on some platforms (e.g. HP-UX
   and Tru64) due to different return values of the `atof()' function.

 * Fixed the `rpl_rotate_logs' test to not fail on certain platforms
   (e.g.  Mac OS X) due to a too long file name (changed
   `slave-master-info.opt' to `.slave-mi').


Bye,
        LenZ
 

si

Administrator
Ну наконец, то!!! Свершилось! :)
Вопрос теперь в том, когда наши провайдеры обновят production MySQL с 3 версии на 4-ю! Вроде как теперь можно, не опасно, а то отмазывались раньше, что мол gamma ненадежно... :)
Есть большое желание узнать как быстро отреагируют на это московские хостеры, пусть народ запостит мессагу, когда у него на хостинге MySQL обновят до 4 версии!
Нажмите для раскрытия...
Это уже проблема провайдеров, в принчипе в mysql 4.0 достаточно много что улучшено исправлено. я сам юзаю 4 версию уже ~пол года проблем практически не возникало.
 
young

young

Новичок
Расскажите мне как полному ламмеру - он stable или нет?!
 

si

Administrator
Расскажите мне как полному ламмеру - он stable или нет?!
Нажмите для раскрытия...
читаем внимательно:
Starting with MySQL 4.0.12, MySQL 4.0 is now labelled as "production"
instead of "gamma".

Users of MySQL 3.23 are encouraged to upgrade, since MySQL 3.23 will now
be phased out slowly. It will still be supported, but only critical bug
and security fixes will be applied to the 3.23 code base.
Нажмите для раскрытия...
 

RomikChef

Guest
dak, а можно выскажутся другие пользователи, которые НЕ ХОТЯТ, чтобы хостер метался, как мартовский заяц, менять отлаженую рабочую конфигурацию, на которой работают сотни пользователей, на вышедший вчера релиз?

Хочется новшеств? Колокейшен нынче дешев. Вперед и с песней, ставь хот оракл. Но тогда самому за свой сервер отвечать придется. Страшно? А провайдер на сотни таких отвечает. И отвечать ему придется конкретно, если на следующей неделе вылетит секьюрити релиз или обнаружится какая-то несовместимость.
 

dak

Guest
dak, а можно выскажутся другие пользователи, которые НЕ ХОТЯТ, чтобы хостер метался, как мартовский заяц, менять отлаженую рабочую конфигурацию, на которой работают сотни пользователей, на вышедший вчера релиз?
Нажмите для раскрытия...
Ну знаешь, MySQL уже давно достаточно стабильные версии 4.x, на то они и "gamma" придумали, на то и лучшими валидаторами утечки памяти проверяют... А ты тут дело выставляешь, как будтно это самая глючная версия на свете... :)

Колокейшен нынче дешев. Вперед и с песней, ставь хот оракл. Но тогда самому за свой сервер отвечать придется. Страшно? А провайдер на сотни таких отвечает.
Нажмите для раскрытия...
Слушай Ромик, каждый живет по средствам. Не надо рассказывать мне про то что для кого дешево, если у тебя деньги девать некуда... Я плачу провайдеру деньги, за то что он делает. И становится сисадмином своего сервера не собираюсь. И имею право хотеть и желать Апгрейда на новое программное обеспечение!

Помнишь переход от PHP 4.2.2 к следующим 4.2.3 или 4.3.0... там то же были трудности, и у многих кривой код не работал, так что же теперь из за них до конца века на старье работать? Если бы такие консерваторы как ты принимали решение, то мы бы до сих пора на всяком старье сидели...
 
Войдите или зарегистрируйтесь для ответа.
Сверху