Перевод инфраструктуры 1С на PostgreSQL — это ответственный процесс, который требует понимания специфики взаимодействия платформы с этой СУБД. Часто администраторы сталкиваются с тем, что стандартные методы работы с базами данных, привычные по MS SQL или ручному управлению в PGAdmin, приводят к ошибкам. В рамках данной статьи мы разберем, почему нельзя создавать базу вручную, как избежать сообщения о «непригодности» базы и что делать с тяжелыми запросами при расчете себестоимости.
Рассмотрим ситуацию: вы установили PostgreSQL, зашли в PGAdmin, создали пустую базу и попытались подключить её к 1С. В этот момент платформа выдает ошибку, сообщая, что база непригодна. Проанализируем причины такого поведения системы.
Во-первых, 1С требует строго определенных настроек локали (Collation) и кодировки. Если при ручном создании базы была выбрана кодировка UTF-8 без учета требований платформы или системный LC_COLLATE не соответствует российским стандартам (обычно это Russian_Russia.1251), платформа не сможет корректно работать с индексами и строковыми данными.
Во-вторых, при создании информационной базы средствами 1С, платформа выполняет ряд критически важных действий:
Config, Params и других.fast_truncate (в специальных сборках).Выясним правильный алгоритм действий. Для создания базы необходимо использовать Консоль администрирования кластера серверов 1С:Предприятия или диалоговое окно добавления базы в списке информационных баз. При этом в полях настройки нужно указать данные сервера PostgreSQL, а саму галочку «Создать базу в случае отсутствия» оставить включенной. В этом случае 1С сама подаст команду серверу СУБД на создание базы с нужными параметрами.
Часто возникает вопрос: можно ли использовать обычный PostgreSQL с официального сайта разработчика? Разберем, почему для стабильной работы УПП или ERP это не рекомендуется. Сборки PostgreSQL от «1С» или «Postgres Pro 1C» содержат патчи, без которых работа платформы будет сопровождаться ошибками.
Проанализируем основные отличия сборки 1С:
Попытка — Исключение. Стандартный PostgreSQL иначе обрабатывает точки сохранения (savepoints), что может привести к непредсказуемому поведению при откате транзакций.Conflicting lock.Посмотрим на ситуацию, описанную в сообщениях форума: после успешной установки и загрузки данных в УПП, при проведении документа «Расчет себестоимости выпуска» возникает ошибка СУБД Error: Aggref found in non-Agg plane node. Это специфическая проблема планировщика запросов PostgreSQL, которая часто проявляется в версиях 10, 11 и 12.
Суть проблемы заключается в том, что планировщик некорректно распределяет агрегатные функции при формировании плана параллельного выполнения сложного запроса. В УПП расчет себестоимости — это огромный запрос с множеством временных таблиц и вложенных соединений.
Разберем способы преодоления этой ошибки по шагам:
Начиная с 11-й версии PostgreSQL, механизм JIT (Just-In-Time compilation) включен по умолчанию или активно используется. Часто именно он вызывает конфликты при выполнении сложных агрегатов. Попробуем его отключить.
Для этого в файле postgresql.conf необходимо найти и изменить следующие параметры:
jit = off
После изменения параметра требуется перезапуск службы сервера PostgreSQL.
Ошибка часто возникает именно на «параллельных» планах. Мы можем запретить планировщику использовать распараллеливание для сложных запросов 1С. В том же файле конфигурации установим:
max_parallel_workers_per_gather = 0
Это заставит сервер выполнять запрос в одном потоке, что исключит возникновение ошибки распределения агрегатов (Aggref) между узлами плана.
Для тяжелых конфигураций, таких как «Управление производственным предприятием», стандартных настроек PostgreSQL недостаточно. Проанализируем параметры, которые критически важны для стабильности расчетов:
max_locks_per_transaction = 256 (или 512 для очень крупных баз).off. Это поможет избежать лишних предупреждений при обработке специфических строк в старых релизах 1С.off, если используется платформа старых релизов или специфический код.Как отмечается в сообщениях форума, иногда радикальным и правильным решением является обновление. Проблема с Aggref была признана багом и исправлялась как в новых минорных версиях PostgreSQL, так и путем оптимизации запросов в самой платформе 1С. Если вы используете PostgreSQL 10 или 11, рассмотрите возможность перехода на версию 12 или 13, но только в связке с актуальной платформой (не ниже 8.3.18), где алгоритмы формирования запросов к Postgres были пересмотрены.
Также стоит обратить внимание на модуль ПроцедурыРасчетаСебестоимостиВыпуска. Если ошибка сохраняется даже на настроенном сервере, убедитесь, что релиз вашей конфигурации УПП актуален. В некоторых случаях 1С выпускала патчи для кода конфигурации, которые упрощали запросы, делая их «перевариваемыми» для планировщика PostgreSQL.
Подводя итог, можно сказать, что стабильная работа 1С на PostgreSQL возможна только при комплексном подходе: использовании правильного дистрибутива, создании базы через кластер 1С и тонкой настройке планировщика запросов в конфигурационных файлах сервера.