Как исправить ошибку "invalid memory alloc request size" при бэкапе базы 1С на PostgreSQL?

При администрировании крупных баз данных 1С (особенно таких как "Управление производственным предприятием" или "ERP"), развернутых на PostgreSQL, системные администраторы часто сталкиваются с ошибкой при попытке создания резервной копии через pg_dump. Сообщение об ошибке выглядит следующим образом: pg_dump: error: Error message from server: ERROR: invalid memory alloc request size 1462250959. Проблема локализуется в таблице public.config при выполнении команды COPY TO stdout.

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

Выясним причину возникновения ошибки

Проанализируем техническую сторону вопроса. Ошибка invalid memory alloc request size в PostgreSQL возникает, когда сервер пытается выделить под один объект (поле в строке таблицы) объем памяти, превышающий внутренний лимит MaxAllocSize. В стандартных сборках PostgreSQL этот лимит составляет 1 ГБ.

В контексте 1С проблема чаще всего проявляется в таблице config. Эта таблица хранит метаданные конфигурации, включая файлы основной конфигурации, конфигурации поставщика и расширений. Если конфигурация базы сильно доработана или находится на поддержке у нескольких поставщиков одновременно, размер одной записи в поле binarydata может превысить 1 ГБ в распакованном виде. В результате pg_dump не может считать эту строку для передачи в поток бэкапа.

Способ 1. Оптимизация таблицы config через удаление конфигураций поставщика

Это наиболее правильный и "чистый" метод решения. Рассмотрим его подробнее. Зачастую база годами накапливает старые конфигурации поставщиков после обновлений, которые фактически не нужны, но занимают место в таблице config.

1. Откроем базу в режиме Конфигуратор.
2. Перейдем в меню Конфигурация — Поддержка — Настройка поддержки.
3. Проанализируем список конфигураций поставщиков. Если их несколько (например, УПП + отраслевой модуль + еще одно решение), это основной кандидат на создание проблемы.
4. Если это допустимо, снимем с поддержки неиспользуемые или дублирующие конфигурации поставщика. Это приведет к физическому удалению соответствующих записей из таблицы config.
5. После выполнения действий обязательно запустим Тестирование и исправление (ТиИ) с включенной опцией "Сжатие таблиц" (или выполним VACUUM FULL config средствами СУБД, предварительно обеспечив монопольный доступ к базе).

Способ 2. Использование параметров исключения таблиц в pg_dump

Если нам необходимо срочно сделать бэкап данных (также можно рассмотреть создание резервной копии в режиме Предприятие), а очистка конфигурации занимает слишком много времени или невозможна, мы можем использовать обходной путь. Разберем, как сделать раздельный дамп.

Выполним выгрузку основной части базы, исключив проблемную таблицу config. Для этого используем параметр --exclude-table:

pg_dump -h localhost -U postgres -d your_database_name --exclude-table=public.config -F c -f "db_data_without_config.backup"

Таблицу config в этом случае придется бэкапить отдельно или восстанавливать из другого источника (например, загрузкой файла .cf в пустую базу). Однако стоит помнить, что без этой таблицы база данных будет неработоспособна, так как в ней хранятся все описания метаданных.

Способ 3. Переход через файловый вариант базы (Метод "dt")

Рассмотрим ситуацию, когда база переносится с MSSQL на PostgreSQL. Это типичный сценарий, при котором ошибка проявляется впервые (так как в MSSQL лимиты на размер поля реализованы иначе).

1. Выгрузим базу из исходной СУБД в файл .dt.
2. Загрузим этот .dt в файловый вариант базы. Несмотря на ограничения размера таблиц в файловой версии (4 ГБ), общая база может быть гораздо больше (20-30 ГБ и более). Главное, чтобы сама таблица config "пролезла" в лимит.
3. В файловом варианте выполним Тестирование и исправление. Посмотрим на результат: 1С при перепаковке может оптимизировать хранение внутренних объектов.
4. Выгрузим заново из файловой базы в .dt и попробуем загрузить в PostgreSQL.

Способ 4. Физическое резервное копирование (pg_basebackup)

Поскольку ошибка invalid memory alloc специфична именно для логического дампа (когда сервер читает содержимое полей), физическое копирование файлов базы данных этой проблеме не подвержено. Проанализируем использование pg_basebackup.

Этот инструмент копирует файлы данных "как есть" на уровне байтов. Для сервера это просто набор файлов, он не пытается анализировать содержимое поля binarydata и не натыкается на ограничение MaxAllocSize.

Преимущества этого метода:

• Гарантированное создание бэкапа вне зависимости от размера конфигурации.
• Высокая скорость создания копии.
• Возможность настройки инкрементальных бэкапов.

Рекомендации по профилактике

Чтобы избежать подобных проблем в будущем, рекомендуем придерживаться следующих правил:

• Контроль расширений: Тяжелые расширения с большими макетами или картинками также записываются в таблицу config (или configcas). Старайтесь не хранить в расширениях бинарные данные большого объема.
• Версия платформы: В свежих релизах платформы (начиная с 8.3.22) механизмы работы с хранилищем конфигурации были оптимизированы. Рассмотрим возможность обновления платформы до актуальной.
• Регулярное обслуживание: Выполнение VACUUM и ANALYZE для таблиц config, configcas и params помогает поддерживать базу в оптимальном состоянии и вовремя заметить раздувание таблиц.

Таким образом, мы выяснили, что ошибка вызвана жестким ограничением PostgreSQL на размер одного поля. Самым надежным решением является оптимизация списка конфигураций на поддержке или переход на физические методы резервного копирования.