Переход на новые версии технологической платформы 1С:Предприятие и обновление систем управления базами данных (СУБД) — это всегда ответственный шаг, который часто преподносит неприятные сюрпризы системным администраторам и программистам. Одной из наиболее коварных проблем, с которой столкнулось сообщество при связке платформы 1С:Предприятие 8.3.13 (и выше) с СУБД PostgreSQL версии 10.5, стала критическая ошибка СУБД: "ERROR: variable not found in subplan target lists".
Эта ошибка внезапно прерывает работу пользователей в самых критически важных точках: при формировании Оборотно-сальдовой ведомости (ОСВ), открытии документов установки цен, формировании книги продаж или подборе номенклатуры. В рамках данной статьи мы подробно разберем природу этого системного сбоя, проанализируем, почему стандартные запросы 1С приводят СУБД в замешательство, и рассмотрим по шагам как временные обходные пути, так и окончательное решение технической проблемы.
Для начала давайте разберемся, что именно происходит под капотом СУБД в момент возникновения ошибки. Сообщение variable not found in subplan target lists генерируется непосредственно ядром СУБД PostgreSQL (а именно модулем планировщика запросов setrefs.c). Оно означает, что планировщик в процессе оптимизации сложного SQL-запроса не смог сопоставить переменную из верхнего уровня выборки с выходными списками (target lists) сформированных подпланов.
Платформа 1С:Предприятие при трансляции запросов из своего внутреннего объектного языка в нативный SQL генерирует огромные конструкции. Особой сложностью отличаются запросы к виртуальным таблицам (остатков, оборотов) и отчеты, построенные на Системе компоновки данных (СКД). Эти запросы содержат:
UNION ALL и LEFT JOIN.CASE WHEN ... THEN ... ELSE ... END.В сборках PostgreSQL, оптимизированных под нужды 1С (от компаний Postgres Pro и самой фирмы 1С), используется специализированный патч для оптимизации удаления избыточных соединений — так называемый 00007-remove_selfjoin.patch. Из-за логической ошибки в данном патче при определенных сценариях (например, когда во вложенных запросах используются группировки, а типы возвращаемых колонок в разных ветках UNION не совпадают до конца или содержат выражения с константами) планировщик СУБД некорректно перестраивает дерево запроса. Он буквально "теряет" ссылку на физическую колонку таблицы, что и приводит к аварийному завершению транзакции.
Этим объясняется тот факт, почему ошибка плавающая: на определенных периодах (например, при формировании ОСВ с первого по последнее число месяца) запрос падает, а при изменении границ периода на один день — выполняется успешно. Изменение параметров выборки заставляет планировщик строить другую ветку плана выполнения, где ошибочный алгоритм оптимизации self-join просто не задействуется.
Если вам необходимо срочно вернуть работоспособность системы, а возможности немедленно обновить СУБД или платформу у вас нет, разработчики СУБД рекомендуют прибегнуть к изменению конфигурационного файла PostgreSQL.
Основной инструмент влияния на оптимизатор в данном контексте — это параметр join_collapse_limit в конфигурационном файле postgresql.conf. Этот параметр указывает планировщику, до какого предела ему разрешено объединять явные конструкции JOIN во вложенные списки для поиска оптимального порядка связывания таблиц.
Рассмотрим, как изменить этот параметр и к чему это приведет:
postgresql.conf в директории данных вашей СУБД.join_collapse_limit (по умолчанию в сборках 1С он часто равен 20).Важное предупреждение: Изначально техническая поддержка рекомендовала выставить значение:
join_collapse_limit = 1
Однако практика реальной эксплуатации информационных баз 1С показала, что установка лимита в значение 1 полностью отключает оптимизацию слияния явных соединений. Это действительно «лечит» падение Оборотно-сальдовой ведомости, но приводит к катастрофическому падению производительности на других участках системы. Например, документы "Установка цен номенклатуры" в Управлении торговлей (УТ) или отчеты по анализу себестоимости начинают зависать и выполняться бесконечно долго.
Экспериментальным путем администраторы баз данных выявили компромиссное значение:
join_collapse_limit = 2
При значении 2 планировщик все еще способен обходить ошибочную ветку оптимизации при построении ОСВ в Бухгалтерии предприятия, но при этом запросы в Управлении торговлей (включая установку цен) выполняются за приемлемое время. Для некоторых крупных конфигураций (таких как ERP или Комплексная автоматизация) может потребоваться подбор значений в диапазоне от 2 до 8. Помните, что после каждого изменения параметра в файле postgresql.conf необходимо перезапускать службу PostgreSQL или выполнять команду перечитывания конфигурации:
SELECT pg_reload_conf();
Если вы столкнулись с проблемой локально, и она мешает работе конкретного бухгалтера при формировании ОСВ, можно попробовать обойти ошибку без вмешательства в настройки СУБД.
Проанализируем структуру компоновки данных Оборотно-сальдовой ведомости. Ошибка часто проявляется из-за специфического формирования секций выборки итогов по забалансовым счетам или при расчете развернутого сальдо.
Выполните следующие шаги в интерфейсе отчета:
Что делать, если отчет "зациклился" и падает сразу при открытии? Поскольку 1С запоминает последние настройки пользователя, при открытии ОСВ программа будет пытаться сформировать отчет сбойной конфигурации и сразу вылетать. Чтобы разорвать этот замкнутый круг, откройте отчет через "Все функции" (Функции для технического специалиста) или воспользуйтесь очисткой сохраненных настроек пользователя в режиме "Администрирование" -> "Настройки пользователей и прав" -> "Очистка настроек".
Описанные выше меры являются временными костылями (workarounds), которые снижают общий потенциал оптимизации вашей СУБД. Чтобы полностью ликвидировать ошибку без ущерба для скорости работы 1С, необходимо обновить компоненты системы.
Разработчики СУБД PostgreSQL совместно со специалистами 1С оперативно исправили дефект в логике работы патча self-join. Ошибка планировщика полностью устранена в официальных сборках PostgreSQL от фирмы 1С, начиная с версии 10.5-24.1C и выше.
Разберем по шагам правильный алгоритм обновления СУБД:
Перед любыми манипуляциями с сервером баз данных создайте резервные копии всех информационных баз. Наиболее надежный способ для СУБД под управлением PostgreSQL в связке с 1С — это выгрузка баз в файлы .dt средствами Конфигуратора 1С, либо создание бинарного дампа СУБД с помощью утилиты pg_dump:
pg_dump -U postgres -F c -b -v -f "backup_db.backup" имя_базы_данных
Скачайте дистрибутив PostgreSQL версии не ниже 10.5-24.1C (или более современные ветки Postgres Pro Standard / 1С-PostgreSQL 11.x, 12.x и далее). Выполните установку обновления в соответствии с вашей операционной системой (Windows Server или Linux Linux-дистрибутивы CentOS/Debian). При установке убедитесь, что применяются официальные патчи для интеграции с 1С.
После успешного обновления СУБД крайне важно актуализировать статистику планировщика и перестроить индексы таблиц. Это необходимо, так как старые индексы и накопленная статистика распределения данных могут заставить планировщик даже обновленной СУБД использовать неэффективные старые пути выполнения запросов.
Для этого выполните переиндексацию баз данных. Вы можете сделать это двумя способами:
Способ первый (Административными средствами СУБД через консоль psql или pgAdmin):
REINDEX DATABASE имя_вашей_базы_данных;
ANALYZE;
Способ второй (Средствами платформы 1С):
После перехода на исправленный релиз PostgreSQL 10.5-24.1C (или выше) и выполнения полной переиндексации вы можете вернуть значение параметра join_collapse_limit к стандартным производительным показателям (от 8 до 20) в файле postgresql.conf. Ошибка variable not found in subplan target lists больше не побеспокоит ваших пользователей, а отчеты и документы будут открываться максимально быстро.