По мотивам топика internal Firebird consistency check (Too many savepoints (287) в FB 3.0.4
В базе на FB 2.5, где работает 70 пользователей, потребление памяти процессом сервера составляет в среднем 1,2 Гб.
В базе на FB 3.0, где обычно работает не более 12 пользователей, потребление памяти процессом сервера составляет в среднем 1,4 Гб. Видимо, по этой причине и произошел тот инцидент.

Начал разбираться. В FB 3.0 каждое подключение к базе через isql сразу увеличивает размер процесса сервера на 30 Мб. Каждое подключение программы - на 50 Мб.
В базе есть триггер на подключение, где проверяется наличие пользователя. Если его закомментировать или деактивировать, то при первом подключении процесс занимает 16 Мб.
При применении в триггере этой строки:


размер процесс увеличивает уже до 32 Мб. Многократное подключение/отключение второго коннекта дает увеличение/уменьшение размера процесса до 47.3 и 37.6 Мб соответственно. Выключение этого запроса приводит к дельте в 2 Мб.
В FB 2.5 такая же логика работы приводит к увеличению размера процесса сервера всего лишь на 0.2 Мб.

В конце триггера выполняется запрос:


Его комментирование уменьшает размер процесса примерно на 30 Мб. У таблицы нет триггеров. Замена на аналогичную таблицу дает такой же результат. Если брать таблицу без зависимостей, то размер увеличивается незначительно.
Итого: в FB 3.0.4 я вижу утечку памяти при работе с таблицами, у которых есть зависимости, в триггере ON CONNECT.

Вопросы разработчикам:
1. Нормально ли, что каждое новое подключение (без DB-триггера) увеличивает размер процесса сервера FB 3.0.4 (SS) на 1,8 Мб, а FB 2.5.7 на 0.1 Мб?
2. Достаточно ли описания проблемы с утечкой памяти в триггере ON CONNECT или вам требуется test-case для исправления?

Симонов Дениси ещё возник закономерный вопрос зачем в конце триггера используется запрос с автономной транзакцией? Если этот запрос действительно последний в триггере, то после него уже не может быть ошибок. Триггеры на подключение и так выполняются в отдельной транзакции.
Там несколько запросов в автономной транзакции. Проверял без нее - то же самое.

Симонов ДенисВ 3.0 кеш метаданных отдельный на каждое соединение. в отличие от FB 2.5 SS, где он общий.
Видимо, это оно и есть.
Я закомментировал триггер и перенес его тело в EXECUTE BLOCK. После подключения размер процесса сервера 16.8 Мб, после подготовки EB - 50.3 Мб.
При подключении с активным триггером - размер процесса 54,5 Мб. Подготовка EB уже не увеличивает размер процесса.
Так что придется переезжать на х64.