Как исправить ошибку СУБД "could not find replacement targetlist entry for attno" в 1С при работе с PostgreSQL

← На главную

В процессе эксплуатации связки платформы 1С:Предприятие 8.3 и СУБД PostgreSQL администраторы и разработчики иногда сталкиваются с внезапными аварийными завершениями работы пользователей. Одним из наиболее неприятных и труднодиагностируемых сбоев является критическая ошибка СУБД: ERROR: could not find replacement targetlist entry for attno XX. После появления этого сообщения сеанс работы в 1С аварийно завершается, а в логах фиксируется невосстановимая ошибка при выполнении POST-запроса к ресурсу /e1cib/logForm.

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

Выясняем техническую причину сбоя: почему PostgreSQL "теряет" колонки

Для того чтобы понять природу этой ошибки, нам необходимо заглянуть во внутренние механизмы работы планировщика запросов (Query Planner) и оптимизатора PostgreSQL. Ошибка could not find replacement targetlist entry for attno XX (где вместо XX выводится конкретный порядковый номер колонки, например, 15 или 22) является внутренним багом ядра PostgreSQL, связанным с механизмом перезаписи запросов (Query Rewriter) и оптимизацией планов выполнения.

Рассмотрим детально, как это происходит:

Платформа 1С при проведении сложных документов (особенно расчетных) активно использует механизм временных таблиц. В рамках транзакции создаются десятки временных таблиц, в которые динамически записываются промежуточные результаты расчетов.
Для оптимизации записи и последующей выборки платформа 1С генерирует сложные SQL-запросы с использованием конструкции RETURNING (например, INSERT INTO ... RETURNING ... или UPDATE ... RETURNING ...).
В СУБД PostgreSQL планировщик сопоставляет физические атрибуты (колонки) таблиц с логическим списком возвращаемых полей — так называемым targetlist. Каждая колонка внутри движка СУБД идентифицируется по своему номеру — attno (attribute number).
При определенных условиях — когда структура временных таблиц динамически меняется платформой 1С в процессе выполнения одного пакета запросов, либо при использовании сложных вложенных подзапросов с группировками — планировщик PostgreSQL теряет соответствие между физическим номером колонки attno и логическим списком targetlist.
В результате планировщик падает в панику, генерируя аварийное исключение, которое транслируется платформе 1С как ошибка СУБД, приводя к немедленному закрытию клиентского приложения.

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


-- Схематичный пример запроса, вызывающего сбой оптимизатора
SELECT 
    temp_table_1.id, 
    temp_table_1.period,
    subquery.calculated_value
FROM temp_table_1
LEFT JOIN (
    SELECT 
        parent_id,
        col_1,
        col_2,
        col_15 AS calculated_value -- Ошибка планировщика при попытке найти attno 15
    FROM temp_table_2
    WHERE col_active = true
    GROUP BY parent_id, col_1, col_2, col_15
) subquery ON temp_table_1.id = subquery.parent_id;

Условия воспроизведения ошибки в решениях 1С

Анализ практических кейсов показывает, что наиболее часто данная ошибка проявляется в конфигурациях 1С:Зарплата и управление персоналом (ЗУП 3.1) и 1С:Зарплата и кадры государственного учреждения (ЗГУ 3.1) при попытке ввести исправление или провести документ Больничный лист.

Проанализировав поведение системы, специалисты выявили ключевую закономерность воспроизведения сбоя:

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

Данная проблема была зафиксирована на СУБД PostgreSQL версий 11.5-1.1C и некоторых сборках ветки PostgreSQL 10.8-13.1C под управлением платформ 1С:Предприятие версий 8.3.14.x и 8.3.15.x.

Разбираем способы решения проблемы

Если вы столкнулись с ошибкой could not find replacement targetlist entry for attno, у вас есть несколько путей ее решения — от быстрых временных мер до кардинального устранения первопричины.

Вариант 1. Установка официальных корректирующих обновлений PostgreSQL (Рекомендуемый способ)

Поскольку ошибка кроется непосредственно в коде планировщика запросов СУБД, разработчики из Postgres Professional совместно с фирмой 1С оперативно выпустили исправления. Проблема была полностью устранена в специализированных сборках СУБД.

Для устранения ошибки выполним обновление СУБД до следующих релизов (или более новых):

Если вы используете 11-ю ветку PostgreSQL, обновите СУБД до версии 11.5-7.1C или выше.
Если ваша информационная база работает на 10-й ветке PostgreSQL, обновите СУБД до версии 10.10-4.1C или выше.

Как подтверждает практика администрирования, после перехода на указанные релизы ошибка при расчете больничных листов полностью исчезает, так как патч корректирует логику сопоставления целевых списков атрибутов в оптимизаторе.

Вариант 2. Использование стабильных дистрибутивов от Postgres Professional

Многие системные администраторы отмечают, что стандартные сборки, поставляемые непосредственно фирмой 1С, иногда могут содержать досадные ошибки компиляции или сборки пакетов. В качестве надежной альтернативы рассмотрим переход на дистрибутивы от компании Postgres Professional, которые оптимизированы специально под требования платформы 1С:Предприятие.

Перейдем на специализированный портал СУБД для 1С (например, 1c.postgres.ru).
Скачаем сборку СУБД Postgres Pro Standard или специализированную бесплатную сборку для 1С соответствующей версии.
Проведем установку и перенос баз данных на новую сборку. Данные сборки проходят более тщательное предварительное тестирование под нагрузкой 1С, что минимизирует вероятность встречи с платформенными багами ядра СУБД.

Вариант 3. Временный откат на стабильные прошлые версии СУБД

Если у вас нет возможности оперативно согласовать и провести обновление СУБД на продакшн-сервере до последних патчей, но расчетный отдел требует срочно провести больничные листы, рассмотрим варианты временного даунгрейда (отката) версии PostgreSQL:

Откат на PostgreSQL 9.6.x: Данная ветка СУБД является одной из самых проверенных временем и стабильных. На версиях 9.6.7 и выше указанный баг планировщика гарантированно отсутствует.
Откат на стабильный релиз 10-й ветки: Если вы не хотите возвращаться на устаревшую 9.6, стабильным промежуточным решением в десятой ветке СУБД долгое время считался релиз PostgreSQL 10.5-24.1C. На нем проведение перерасчетов в ЗУП также проходит без аварийных завершений.