• Запрос аварийно прерывается с ошибкой ERROR: 54000: program limit exceeded.
• Сбои сложных иерархических отчетов в 1С при выполнении бесконечных или глубоких рекурсий.
• Падение операций создания индексов или группировок при превышении лимитов структур данных.
• Отказ выполнения динамически сгенерированных аналитических SQL-запросов.

1. Анализ текста ошибки и первопричины

Код 54000 является базовым для класса переполнения программных лимитов. Точная причина всегда детализируется в сопровождающем сообщении лога (например, превышение глубины стека, размера кортежа или лимита структур).

grep -E "54000|limit exceeded" /var/log/postgresql/postgresql-*.log

2. Устранение зацикливания в рекурсивных запросах (Recursive CTE)

Самая частая причина ошибки — зацикливание рекурсивного обхода деревьев/справочников. Добавьте ограничение глубины рекурсии или проверку циклов:

-- Безопасный рекурсивный запрос с ограничением глубины и защитой от зацикливания
WITH RECURSIVE hierarchy_tree AS (
    SELECT id, parent_id, 1 AS depth, ARRAY[id] AS path
    FROM catalog_items WHERE parent_id IS NULL
    
    UNION ALL
    
    SELECT c.id, c.parent_id, h.depth + 1, h.path || c.id
    FROM catalog_items c
    JOIN hierarchy_tree h ON c.parent_id = h.id
    WHERE NOT c.id = ANY(h.path) -- Защита от бесконечного цикла
      AND h.depth < 100          -- Защита от превышения лимита вызовов
)
SELECT * FROM hierarchy_tree;

3. Настройка глубины стека ядра (max_stack_depth)

Если сложные вложенные функции падают из-за безопасного лимита стека, скорректируйте max_stack_depth в postgresql.conf (значение должно быть минимум на 1MB меньше системного ulimit -s):

# Проверка системного лимита в Linux (обычно 8192KB)
ulimit -s

-- Увеличение лимита в postgresql.conf (например, до 6MB при ulimit 8MB)
ALTER SYSTEM SET max_stack_depth = '6MB';
SELECT pg_reload_conf();

4. Оптимизация тяжелых сортировок и группировок

При нехватке памяти для построения внутренних хеш-таблиц увеличьте work_mem для проблемной сессии:

SET work_mem = '256MB';