Как исправить ошибку СУБД 42P01 при сохранении базы данных в PostgreSQL?

В процессе обновления конфигурации базы данных или сохранения изменений в Конфигураторе администраторы и разработчики могут столкнуться с критическим сбоем. Платформа 1С аварийно прерывает процесс и выводит системное сообщение: Ошибка СУБД: 42P01: ОШИБКА: отношение "_inforgchngr...x1" не существует. Разберем детально, почему возникает эта ошибка и какими способами можно вернуть базу данных в рабочее состояние.

Анализ структуры имени таблицы и причины сбоя

Для понимания сути проблемы проанализируем имя отсутствующей таблицы. Префикс _InfoRgChngR указывает на таблицу регистрации изменений механизма планов обмена для конкретного регистра сведений. Числовой идентификатор (например, 73857) представляет собой внутренний номер объекта метаданных. В 1С его точное имя можно сопоставить программным методом ПолучитьСтруктуруХраненияБазыДанных(). Окончание X1 однозначно свидетельствует о том, что объект добавлен или модифицирован с использованием расширения конфигурации.

Код 42P01 в PostgreSQL сообщает об отсутствии запрашиваемого отношения в схеме данных. В процессе обновления конфигурации движок реструктуризации формирует запрос переноса записей из старой таблицы в новую через конструкцию INSERT INTO ... SELECT ... FROM. Однако из-за ошибки в логике работы платформы с объектами расширений физическая таблица изменений в СУБД создана не была, что и приводит к аварийной остановке.

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

1. Сбой платформенного механизма реструктуризации v2: Начиная с версии 8.3.11, платформа по умолчанию использует оптимизированную серверную реструктуризацию. При определенных условиях (наличие пустых таблиц расширений, переименование объектов) алгоритм дает сбой и пытается прочитать несуществующую вспомогательную таблицу.
2. Ошибки релизов платформы 1С: Некорректное создание сопутствующих таблиц регистрации изменений для расширений зафиксировано как платформенная ошибка в ряде подверсий 8.3.18–8.3.24.
3. Прерванный процесс прошлого обновления: Если предыдущая реструктуризация завершилась аварийно (перезагрузка сервера, таймаут сеанса), служебные таблицы Params, DBSchema и _extensionsrestruct могут содержать несогласованные метаданные.

Способ 1. Создание таблицы-заглушки в PostgreSQL

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

Разберем по шагам порядок действий:

1. Обязательно создаем резервную копию базы данных средствами СУБД.
2. Подключаемся к серверу PostgreSQL через консоль или клиентскую утилиту управления базой.
3. Создаем пустую таблицу с именем _inforgchngr73857x1. Помним, что имена таблиц 1С в PostgreSQL всегда хранятся в нижнем регистре.
4. Определяем структуру полей. Для таблицы регистрации изменений требуются поля _noderef (ссылка на узел плана обмена, тип bytea), _messageno (номер сообщения, тип numeric), а также поля, соответствующие измерениям основного регистра сведений. Типы полей измерений можно подсмотреть в основной таблице _inforg73857.
5. После успешного создания таблицы открываем Конфигуратор и повторно запускаем процедуру Обновить конфигурацию базы данных (клавиша F7). Платформа выполнит выборку из пустой таблицы и корректно доведет реструктуризацию до финала.

Способ 2. Переключение версии механизма реструктуризации

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

Выполним следующие шаги:

1. Переходим в каталог установки сервера «1С:Предприятие» и находим файл конфигурации conf.cfg.
2. Добавляем параметр управления реструктуризацией: dbmsTablesRestructuringVersion=v1
3. Перезапускаем службу сервера 1С.
4. Заходим в Конфигуратор и повторяем обновление конфигурации базы данных.

Способ 3. Тестирование и исправление информационной базы

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

Проведем регламентную диагностику:

1. Создаем резервную копию базы данных.
2. Открываем Конфигуратор и переходим в меню Администрирование — Тестирование и исправление...
3. Устанавливаем флаги на пунктах: Проверка логической целостности информационной базы, Проверка ссылочной целостности информационной базы, Реструктуризация таблиц информационной базы.
4. Запускаем процесс и анализируем служебные сообщения по завершении.

Способ 4. Временное отключение или доработка расширения

Поскольку ошибка напрямую связана с объектами расширений (суффикс X1), проанализируем состояние самого расширения:

1. Выгружаем данные проблемного регистра сведений во внешний файл с помощью универсальной обработки выгрузки и загрузки XML-данных.
2. Отключаем расширение конфигурации или удаляем из него проблемный регистр сведений.
3. Применяем изменения в структуре базы данных.
4. Если функционал регистра необходим для постоянной работы, переносим его из расширения в основную конфигурацию. Таблицы основной конфигурации не имеют суффиксов расширений и значительно более стабильно проходят реструктуризацию на PostgreSQL.
5. Возвращаем сохраненные данные обратно в базу.

Способ 5. Обход через файловый режим

Если база данных имеет умеренный объем, эффективным решением может стать выгрузка в файл .dt. Файловый движок 1С использует собственную архитектуру таблиц и не зависит от специфических запросов PostgreSQL.

Разберем данный алгоритм:

1. Выгружаем информационную базу в файл .dt через меню Конфигуратора.
2. Разворачиваем чистую файловую базу из полученного файла.
3. Выполняем обновление конфигурации в файловом режиме — процесс проходит без ошибок СУБД.
4. Создаем повторную выгрузку .dt из файловой базы.
5. Загружаем файл в пустую, заново созданную базу данных на PostgreSQL.