InterBase: тормозология и глюконавтика
Страница 37. Глюки, которые официально исправлены в 5.5


Глюки, которые официально исправлены в 5.5 (52 шт)

  • Новый установочный скрипт и файл interbaseLICENSE не документированы в README
  • Справка к WISQL не обновлена
  • Сервер повисает из за глюков в менеджере блокировок
  • Вызов хранимой процедуры из InterClient'а вешает сервер (Интересно, они вообще когда-нибудь думают защищать свой протокол?)
  • Обновления, сделанные триггером не отматываются при rollback (Ни чего себе!)
  • Исключения (а при некоторых кодировках, включая win1251 - порча базы) при попытках перекодировать из Unicode_fss
  • Слишком большое количество версий метаданных портит базу, в частности, из за многих alter trigger (Надо учитывать. Правда, не говорят, при каком количестве.)
  • Большое количество grant'ов на одну таблицу портит базу
  • Невозможно загрузить gdsintl, если interbase установлен в путь, включающий точку. Обходной путь задокументирован
  • Запрос ко вьюшке, основанной на другой вьюшке, обрушивает сервер
  • gfix -attach не даёт активной транзакции завершиться
  • Многопользовательский тест допускает только 96 подключений к NT
  • Восстановление из бэкапа может не пройти, если база содержит хранимую процедуру, основанную на вьюшке
  • "WARNING: column EM_FNAME is not defined in table RDB$PAGES" (Я это видел, когда разбэкапливал базу 4 утилитой gbak 5.1. Главная странность в том, что RDB$PAGES не имеет отношения к полям.)
  • cast() возвращает неправильный результат для чисел numeric < 1
  • Улучшение документации на лицензирование 5.0
  • Преобразование numeric в char даёт ошибку, если char() слишком длинный
  • Преобразование максимального по модулю отрицательного целого в строку даёт ошибку
  • Ошибки при select'ах на внешних файлах
  • Слишком большое количество (свыше 200) alter table в скрипте приводят к сообщению "request depth exceeded"
  • isc_info_base_level врёт о версии базы
  • gbak портит принадлежность хранимых процедур пользователям
  • gbak не проходит на некоторых базах, содержащих триггера для поддержки ссылочной целостности
  • gbak портит принадлежность таблиц пользователям (По-моему, они это уже исправляли. Дежа вю?)
  • grant на хранимые процедуры ведёт себя глючно
  • rtrim() в запросе select обрушивает сервер (Здесь и далее видимо имеются в виду функции из того dll, который прилагается к версии 5 и выше. Оказывается, он ничем не лучше нашего в его начальном состоянии)
  • Ltrim(), rtrim(), lower() возвращают неправильную длинну строки char()
  • Lower() возвращает некорректные результаты
  • Функции, скомпилированные Borland C++, не возвращают память
  • Дропанье триггера дропает сервер под HP-UX
  • SYSDBA не может сделать revoke, если соответствующие привилегии были переданы пользователем дальше
  • alter trigger inactive обрушивает сервер (ни разу не видел, хотя в 5.0 может и есть)
  • Сервер под NT падает, если триггера по многу раз подряд дропаются или альтерятся
  • Внешние функции иногда обрушивают сервер (Это действительно так, особенно когда не отлажены, но такова уж природа вызова этих функций из недр interbase. Может быть имеется в виду какой-либо случай, когда функция корректна, но сервер падает. Вполне может быть, но подробностей они не разъясняют.)
  • Gbak 5.1.1 иногда не восстанавливает .gbk-файлы, сделанные в предыдущих версиях (Я пробовал восстанавливать 4.0-4.2, всё проходило без особенных неожиданностей. По крайней мере ничего такого, чтобы глючило в 5.x, но не глючило в 4.x. Наоборот - да.)
  • Скрипт ISQL обрушивает сервер (опять не разъясняют детали, конкретных примеров выше - сколько угодно)
  • Alter на процедуру, используемую другой процедурой привощит к отрубающей ошибке bugcheck (Не разъясняют, что значит "использует": то ли активный в данный момент вызов, то ли просто ссылку изнутри тела)
  • show triggers работает очень медленно из-за недоступного системного индекса (То, что у них индексов на метаданных хронически не хватает, глюк известный. А вот чтобы show triggers тормозил, я как-то не замечал.)
  • Многошаговые триггера могут не исполнить все шаги (Ого! Надо учесть.)
  • Объекты базы данные после восстановления из бэкапа принадлежат тому пользователю, под которым делалось подключение для этого восстановления (Похоже, они на этом глюке помешались. Видел сообщения о нём раз 5. Чуть ли не во всех версиях. Интересно, они его всё-таки исправили в 5.5 или в списке глюков 6.0 тоже будет такая же строчка?)
  • Невозможно сделать alter на процедуру, которая ссылается на другую процедуру, если у той изменился список параметров (Ну это мы и без них заметили)
  • Ограничения check не проверяют результаты триггеров
  • Сервер interbase обваливается, если попытаться дропнуть триггер, используемый в данный момент
  • Проблемы в мурыжере, извините, в менеджере блокировок
  • Сервер обваливается, когда проедуру дропают сразу же после вызова
  • Show grant пропускает ключевое слово Trigger (Похоже, у них совсем крыша поехала. Зачем гранты на триггера?)
  • Невенрая проверка права Execute для хранимых процедур
  • Слишком много информационных сообщений в Interbase.log (По-моему, наоборот, слишком мало. Ни в чём разобраться невозможно. Наиболее важные детали, как правило, оказываются опущенными. И повлиять на этот процесс невозможно. Весьма хреново.)
  • Неправильные путь в параметре gsec -database вешает NT Server (Это глюк обоих продуктов)
  • Офигенный рост памяти при восстановлении базы с некоторыми разновидностями взаимозависимых хранимых процедур
  • Commit на некоторых видах хранимых процедур обрушивает свервер (Во-первых, не говорят, что должно быть в процедуре. Во-вторых, не говорят, к чему Commit: к созданию процедуры или к её последующему вызову.)
  • Сервер обрушивается и/или портит базу, если более 50 пользователей одновременно мучают его тяжёлыми запросами достаточно длительный промежуток времени
 
« Предыдущая статья