Монитор производительности (perfmon) 25.100.0 от 02.09.2025
- Улучшен мастер миграции на PostgreSQL.
 - Исправлена ошибка при построении меню панели управления.
 - Исправлена ошибка БД при установке модуля на PostgreSQL.
 
Обновление в основном затрагивает поддержку PostgreSQL, улучшает работу с кастомными подключениями к БД и исправляет мелкие ошибки. Давайте разберем детали.
1. Ключевые изменения
Усилена валидация конфигурации PostgreSQL
Это главное изменение в коммите. Мастер миграции на PostgreSQL (perfmon.pgsql) теперь выполняет две важные проверки конфигурации сервера БД перед началом работы.
Что проверяется:
standard_conforming_strings = on: Этот параметр гарантирует, что строки в SQL-запросах обрабатываются по стандарту, что исключает множество потенциальных проблем с экранированием и SQL-инъекциями.ac_ignore_maclabel = true(если опция доступна): Эта проверка специфична для окружений с MAC (Mandatory Access Control) и предотвращает возможные ошибки доступа.
Где это реализовано:
install/wizards/bitrix/perfmon.pgsql/wizard.php: Добавлена логика проверок.install/wizards/bitrix/perfmon.pgsql/lang/.../wizard.php: Добавлены соответствующие сообщения об ошибках на нескольких языках.
⚠️ Важно: Если вы планируете миграцию на PostgreSQL с помощью встроенного мастера, теперь нужно будет убедиться, что ваш сервер соответствует этим требованиям. Это не "брейкинг", а скорее "фейл-сейф" — защита от развертывания на заведомо некорректной конфигурации.
Улучшена работа с множественными подключениями к БД
В административном меню модуля появилась поддержка кастомных подключений, объявленных в .settings.php, которые могут требовать предварительной загрузки своих модулей.
Было:
Меню просто итерировало все $configParams и выводило ссылку для каждого соединения.
        // bitrix/modules/perfmon/admin/menu.php (старая версия)
foreach ($configParams as $connectionName => $connectionParams)
{
    $connections[] = [
        'text' => $connectionName,
        'url' => 'perfmon_tables.php?lang=' . LANGUAGE_ID . '&connection=' . urlencode($connectionName),
        // ...
    ];
}
    
Стало: Теперь перед формированием пункта меню происходит две проверки:
- Если для соединения указан модуль (
$connectionParams['module']), он будет подключен через\Bitrix\Main\Loader::includeModule(). - Пункт меню будет создан, только если класс соединения (
$connectionParams['className']) является наследником\Bitrix\Main\DB\Connection. 
        // bitrix/modules/perfmon/admin/menu.php (новая версия)
if (isset($connectionParams['module']))
{
    \Bitrix\Main\Loader::includeModule($connectionParams['module']);
}
if (is_a($connectionParams['className'], '\Bitrix\Main\DB\Connection', true))
{
    $connections[] = [ /* ... */ ];
}
    
💡 Что это дает? Теперь в меню производительности будут корректно отображаться только валидные и активные подключения к базам данных, включая те, что реализованы в кастомных модулях (например, для работы с ClickHouse или другими экзотическими БД). Это делает модуль более гибким и отказоустойчивым в сложных конфигурациях.
2. Мелкие исправления и улучшения
Корректное удаление таблицы b_perf_cache_hitrate
В скрипт деинсталляции модуля для PostgreSQL добавлено удаление таблицы b_perf_cache_hitrate. Ранее она могла оставаться в базе данных после удаления модуля.
- Файл: 
install/db/pgsql/uninstall.sql 
Исправление в SQL-парсере
В классе \Bitrix\Perfmon\Sql\Table исправлен пограничный случай, когда парсер мог столкнуться с null-токеном, что приводило к ошибке. Теперь в такой ситуации токен принудительно заменяется на ;, что позволяет избежать падения.
- Файл: 
lib/sql/table.php 
Инсайт: Этот фикс — хороший пример "защитного" программирования. Он нацелен на обработку некорректных или неполных SQL-запросов, которые могут попасть в парсер, и делает его более устойчивым.
3. Интересные находки
В install/db/pgsql/install.sql изменился способ объявления индексов для таблицы b_perf_cache_hitrate. Ранее они были частью CREATE TABLE, теперь вынесены в отдельные команды CREATE UNIQUE INDEX и CREATE INDEX.
Было:
        CREATE TABLE b_perf_cache_hitrate (
    //...
    PRIMARY KEY(ID),
    UNIQUE INDEX UX_HASH(HASH),
    INDEX IX_B_PERF_CACHE_RATE(RATE)
);
    
Стало:
        CREATE TABLE b_perf_cache_hitrate (
    //...
    PRIMARY KEY(ID)
);
CREATE UNIQUE INDEX ux_hash ON b_perf_cache_hitrate (hash);
CREATE INDEX ix_b_perf_cache_rate ON b_perf_cache_hitrate (rate);
    
Это не меняет конечную структуру, но может быть связано с обеспечением лучшей совместимости между разными версиями PostgreSQL или является шагом к унификации скриптов установки.