Как исправить ошибку pg_dump «не удалось разрешить цикл зависимостей» при резервном копировании базы 1С на PostgreSQL?

При администрировании баз данных 1С:Предприятия, работающих под управлением СУБД PostgreSQL, специалисты часто сталкиваются со специфическими предупреждениями в процессе создания резервных копий. Одним из наиболее запутанных является предупреждение утилиты pg_dump, связанное с невозможностью разрешить цикл зависимостей между объектами базы данных. Лог ошибки обычно выглядит следующим образом:

pg_dump: [sorter] ПРЕДУПРЕЖДЕНИЕ: не удалось разрешить цикл зависимостей для следующих объектов:
pg_dump: [sorter]   DUMMY TYPE __document70_vt161_intkeyind  (ID 1208 OID 278566)
pg_dump: [sorter]   DUMMY TYPE _document70_vt161_intkeyind  (ID 2976 OID 278567)
pg_dump: [sorter]   INDEX _document70_vt161_intkeyind  (ID 8410 OID 278565)
pg_dump: [sorter]   POST-DATA BOUNDARY  (ID 9300)
pg_dump: [sorter]   TABLE DATA config  (ID 8929 OID 258801)
pg_dump: [sorter]   PRE-DATA BOUNDARY  (ID 9299)

В этой статье мы подробно разберем природу этого явления, выясним причины его возникновения в среде 1С, оценим риски для сохранности данных и рассмотрим пошаговые методы устранения этой проблемы.

Почему возникает цикл зависимостей в PostgreSQL?

Для того чтобы понять суть проблемы, нам необходимо заглянуть под капот утилиты pg_dump и механизмов работы самой СУБД PostgreSQL. Резервное копирование схемы базы данных — это не просто последовательное копирование таблиц. Утилита должна выгрузить структуру базы в строго определенном порядке, чтобы при последующем восстановлении объекты создавались корректно (например, сначала создается таблица, затем ее индексы, триггеры и внешние ключи).

Для построения этой последовательности pg_dump выполняет следующие действия:

1. Сканирует системные каталоги СУБД (такие как pg_class, pg_depend, pg_type и др.).
2. Строит ориентированный граф зависимостей всех объектов базы данных.
3. Выполняет топологическую сортировку этого графа.

Термин DUMMY TYPE (вспомогательный или фиктивный тип) относится к скрытым типам данных, которые PostgreSQL автоматически создает для каждой таблицы и связанных с ней массивов строк. При нормальном функционировании СУБД эти типы жестко связаны со своими таблицами.

Суть ошибки: Во время активной работы платформы 1С (особенно при реструктуризации таблиц или обновлении конфигурации) в системном каталоге pg_depend могут накопиться некорректные или устаревшие записи. В результате возникает ситуация взаимной (циклической) зависимости: например, индекс указывает на таблицу, таблица зависит от своего скрытого типа, а этот тип ошибочно ссылается на индекс. Сортировщик pg_dump зацикливается, не может определить, какой объект создать первым, выдает предупреждение could not resolve dependency loop и разрывает цикл в случайном месте, чтобы завершить резервное копирование.

Влияет ли это предупреждение на целостность бэкапа?

Важно понимать разницу между критической ошибкой (ERROR) и предупреждением (WARNING). Данное сообщение относится к категории WARNING. Это означает, что:

• Процесс резервного копирования завершается успешно, и сам файл бэкапа создается.
• Физическая целостность пользовательских данных (таблиц документов, справочников, регистров) не нарушена.
• В большинстве случаев такой бэкап успешно развернется на чистой СУБД. При импорте утилита pg_restore воссоздаст структуру, проигнорировав ложные циклические связи.

Однако существует риск того, что при попытке раздельного восстановления схемы (например, только метаданных без данных или наоборот) СУБД выдаст ошибку из-за нарушения порядка создания объектов. Поэтому оставлять систему в таком состоянии крайне не рекомендуется.

Специфика возникновения проблемы в 1С:Предприятии

Проанализировав практический опыт администраторов баз данных, можно выделить две основные причины появления зацикленных зависимостей в связке 1С и PostgreSQL:

1. Ошибки платформы 1С при реструктуризации: Платформа 1С очень активно управляет физической структурой таблиц СУБД. В процессе обновления конфигурации или выполнения процедуры ТестированиеИИсправление (ТиИ) с включенной реструктуризацией, платформе требуется пересоздавать таблицы и индексы. В некоторых релизах платформы (наиболее массово проблема фиксировалась на ветках 8.3.14.х и ранних сборках 8.3.16.х) механизмы реструктуризации отрабатывали некорректно. Платформа удаляла и пересоздавала объекты метаданных, но оставляла «мусорные» связи в системных каталогах PostgreSQL.
2. Ошибки самого планировщика СУБД: В старых минорных версиях PostgreSQL также присутствовали баги сортировщика утилиты pg_dump, которые приводили к ложноположительным срабатываниям на некоторых типах уникальных индексов и связанных с ними функциях.

Рассмотрим подробнее пошаговые методы устранения этого предупреждения.

Метод 1. Перезаливка базы через файл выгрузки (.dt)

Это самый простой, надежный и рекомендуемый способ исправления системных каталогов СУБД. Когда мы выгружаем базу в формат .dt, 1С сохраняет только прикладные данные и конфигурацию, полностью абстрагируясь от физической структуры конкретной СУБД. При последующей загрузке файлы таблиц, индексов и вспомогательных типов создаются в PostgreSQL абсолютно с нуля, что гарантирует отсутствие старых некорректных связей.

Пошаговый алгоритм действий:

1. Запустите информационную базу в режиме Конфигуратор.
2. Убедитесь, что в базе нет активных сессий пользователей.
3. В меню выберите пункт Администрирование -> Выгрузить информационную базу... и сохраните файл с расширением .dt.
4. Откройте консоль администрирования СУБД (например, pgAdmin) или подключитесь по SSH.
5. Удалите текущую базу данных в PostgreSQL.
6. Создайте новую пустую базу данных с тем же именем, указав правильного владельца и кодировку (UTF-8).
7. Вернитесь в Конфигуратор 1С (подключившись к уже новой, пустой базе данных).
8. Выберите пункт Администрирование -> Загрузить информационную базу... и укажите ранее сохраненный файл .dt.

После успешного завершения загрузки запустите процедуру создания бэкапа через pg_dump. Вы увидите, что предупреждение исчезло.

Метод 2. Обновление платформы 1С:Предприятие

Если вы обнаружили, что предупреждение появляется регулярно после каждого проведения реструктуризации или обновления конфигурации, скорее всего, ваша текущая версия платформы содержит баг реструктуризатора. Для регулярного обслуживания ИБ подобные рутинные задачи можно запустить по расписанию, настроив автоматическое архивирование, тестирование и обновление баз 1С в фоновом режиме.

Проанализируем версии платформ: проблема была массовой на релизах 8.3.14. В более поздних версиях платформы (начиная с 8.3.15, а также в современных ветках 8.3.22, 8.3.23 и выше) логика работы с системными каталогами PostgreSQL была существенно переработана и оптимизирована. Обновление платформы на актуальный стабильный релиз позволит избежать повторного появления «мусорных» циклов зависимостей при последующих обновлениях конфигурации 1С.

Метод 3. Обновление и обслуживание PostgreSQL

Иногда корни проблемы кроются в багах самой СУБД. Разработчики PostgreSQL регулярно выпускают минорные обновления, исправляющие ошибки в утилите pg_dump. Рекомендуется:

• Обновить установленную версию PostgreSQL до актуального минорного релиза в рамках используемой ветки (например, если используется PostgreSQL 14, обновите ее до последней доступной версии 14.x).
• В качестве профилактики регулярно выполнять регламентное обслуживание базы данных. Процедура VACUUM FULL совместно с REINDEX помогает СУБД очистить системные таблицы от устаревших версий строк, однако, как показывает практика, сама по себе очистка VACUUM не всегда способна разорвать уже созданные циклические связи в pg_depend без пересоздания объектов.

Метод 4. Полная переинициализация кластера СУБД

В редких и запущенных случаях, когда повреждения затрагивают глобальные системные каталоги всего кластера PostgreSQL, а перезаливка отдельной базы через .dt не приносит долгосрочного результата, администраторы прибегают к радикальному, но действенному методу — переустановке кластера.

Рассмотрим шаги этого процесса:

1. Выгрузите все имеющиеся базы данных 1С в файлы .dt.
2. Остановите службу PostgreSQL.
3. Удалите или переименуйте директорию с данными (каталог data).
4. Выполните инициализацию нового кластера баз данных с помощью утилиты initdb с корректными параметрами локали (например, --locale=ru_RU.UTF-8).
5. Запустите службу PostgreSQL, создайте чистые базы данных и загрузите в них информацию из файлов .dt.

Резюме

Предупреждение pg_dump: [sorter] ПРЕДУПРЕЖДЕНИЕ: не удалось разрешить цикл зависимостей не является фатальным для сохранности ваших данных в 1С. Тем не менее, оно сигнализирует о наличии «мусора» в системном каталоге PostgreSQL, оставленного платформой 1С после реструктуризации таблиц. Наиболее эффективным решением является разовая перезаливка базы через формат .dt в сочетании с последующим обновлением платформы 1С до стабильного современного релиза.