Почему 1С работает только на пропатченном PostgreSQL

Патч PostgreSQL для 1С нужен потому, что оригинальный PostgreSQL не рассчитан на то, как платформа 1С работает с базой. Платформа создаёт огромное число временных таблиц, шлёт сложные запросы с десятками соединений и ждёт определённых планов выполнения. Обычная сборка с сайта postgresql.org на таких нагрузках тормозит, а местами ведёт себя непредсказуемо. Доработанные сборки (их выпускают для 1С отдельно) убирают эти узкие места.

Типичная ситуация: сисадмин поставил свежий PostgreSQL из репозитория дистрибутива, база запустилась, пользователи зашли. Через две недели проведение документов растянулось с секунд до минут, а в списке процессов висят запросы, которые «вчера» отрабатывали мгновенно. Причина часто не в железе, а в том, что СУБД вообще не та, под которую платформа писалась.

Ниже по порядку: что именно меняют патчи, как совместить сборку с платформой, как обновить сервер и где обычно ошибаются.

Что меняется в работе сервера после патча

Платформа 1С при проведении документа создаёт временные таблицы десятками и сотнями. В обычном PostgreSQL каждая такая таблица оставляет следы в системных каталогах (pg_class, pg_attribute). Каталоги пухнут, автовакуум не успевает, и запросы к системным таблицам становятся заметно медленнее.

Доработанные сборки уменьшают эту нагрузку. Заодно они корректируют работу планировщика: он реже выбирает вложенные циклы там, где нужен хеш-join, и точнее оценивает число строк для условий, которые формирует платформа.

Что это даёт на практике:

• ⚡ быстрее проведение и закрытие месяца в больших базах;
• 📉 меньше «прыжков» времени запроса: сегодня 3 секунды, завтра 40;
• 🧹 каталоги не раздуваются, автовакуум справляется;
• 🔒 меньше долгих блокировок на системных таблицах.

Какие ошибки закрывают доработанные сборки

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

Точный перечень изменений зависит от выпуска сборки. Его публикует разработчик сборки вместе с каждой версией, и читать его нужно перед обновлением, а не после.

Как понять, что вам не хватает патча

Прямого индикатора нет, но набор признаков говорит сам за себя. Если совпадают два-три пункта, сборку стоит проверить в первую очередь.

• 🐢 Медленное проведение документов при слабой загрузке процессора и диска.
• 📈 Системные таблицы pg_class и pg_attribute занимают гигабайты при небольшой самой базе.
• 🔁 Автовакуум почти всегда занят системными таблицами.
• 🎲 Одинаковый запрос то летает, то «думает» минуту, а данные не менялись.

Для проверки сравните размеры системных каталогов командой SELECT pg_size_pretty(pg_total_relation_size('pg_attribute'));. Если цифра в разы больше ожидаемой, значит временные таблицы оставляют мусор, и пора выяснить, какая сборка стоит на сервере.

Безопасность: чем опасны старые версии PostgreSQL

PostgreSQL регулярно получает исправления уязвимостей. Каждая младшая версия (например, 16.х) закрывает найденные дыры: от повышения привилегий до чтения чужих данных. Сервер, который не обновляли два-три года, содержит десятки известных уязвимостей, и описания их публичны.

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

Минимум, который стоит сделать:

1. Держать порт 5432 закрытым для интернета, пускать только с адреса сервера 1С.
2. Обновлять младшие версии не реже раза в полгода.
3. Не использовать для 1С учётную запись postgres с простым паролем.
4. Проверить pg_hba.conf: никаких записей с методом trust для сетевых подключений.

Как совместить версию PostgreSQL и платформу

Не любая версия PostgreSQL подходит к любой платформе. Платформа 1С официально поддерживает определённые ветки СУБД, и список меняется от релиза к релизу. Работать «неподдерживаемая» связка может, но при проблемах вы окажетесь без поддержки.

Порядок проверки:

1. Узнайте точный номер платформы (например, 8.3.xx.xxxx) на сервере 1С.
2. Откройте описание этого релиза и найдите раздел о поддерживаемых СУБД.
3. Сверьте мажорную ветку PostgreSQL (14, 15, 16 и так далее) с этим списком.
4. Убедитесь, что сборка именно доработанная, а не обычная.

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

Как установить патч: пошаговая инструкция

Ниже сценарий для обновления младшей версии на сервере с Windows. На Linux логика та же, отличается способ установки: пакеты из репозитория сборки.

Подготовка

• 💾 Сделайте резервные копии всех баз и самого кластера.
• 📝 Запишите текущую версию: SELECT version(); в psql.
• 📁 Скопируйте postgresql.conf и pg_hba.conf в отдельную папку.
• 🕐 Выберите время, когда в базах никто не работает .

Перед любыми изменениями на сервере СУБД проверьте, что резервная копия восстанавливается. Копия, которую ни разу не разворачивали, копией считать нельзя.

Установка

1. Остановите рабочие процессы и службу сервера 1С, чтобы не осталось активных соединений.
2. Остановите службу PostgreSQL.
3. Запустите установщик новой сборки. Каталог данных укажите тот же, что и у старой.
4. Если установщик предлагает инициализировать кластер заново, откажитесь. Иначе есть риск затереть данные.
5. Запустите службу PostgreSQL и проверьте журнал на ошибки запуска.
6. Выполните SELECT version(); и убедитесь, что версия сменилась.
7. Запустите сервер 1С и откройте несколько баз.

Затем проверьте, что настройки на месте: сравните свои копии postgresql.conf и pg_hba.conf с рабочими. Установщик иногда подставляет значения по умолчанию.

Если нужна конкретная версия сборки

Иногда нужна не последняя сборка, а определённая: например, чтобы совпала с тестовым стендом или потому, что новая ещё не проверена на вашей нагрузке. Тогда:

• скачайте именно нужный дистрибутив, а не «последний»;
• на Linux закрепите версию пакета, чтобы автоматическое обновление не перешло на следующую;
• в Windows храните установщик рядом с документацией по серверу: старые версии потом найти сложнее.

# Debian/Ubuntu: запретить автоматическое обновление пакета
sudo apt-mark hold имя-пакета-postgresql

# Снять запрет, когда будете готовы обновляться
sudo apt-mark unhold имя-пакета-postgresql

Имя пакета зависит от сборки, посмотрите его командой dpkg -l | grep postgres.

Установка на Linux: что отличается

На Linux доработанную сборку обычно ставят из подключённого репозитория разработчика, а не из репозитория дистрибутива. Это важно: одноимённые пакеты в системном репозитории могут оказаться обычными, и менеджер пакетов с радостью «обновит» вашу сборку на стандартную.

Что сделать до первого обновления:

1. Подключите репозиторий сборки и проверьте приоритет источников.
2. Выясните, откуда установлен пакет: apt policy имя-пакета (Debian, Ubuntu) или dnf info имя-пакета (семейство RHEL).
3. Закрепите версию, как показано выше, если обновление должно идти вручную.
4. Проверьте права на каталог данных: владелец должен остаться postgres.

После установки откройте журнал службы командой journalctl -u postgresql -n 100 и убедитесь, что кластер запустился без предупреждений.

Настройки после обновления: что проверить

Обновление сборки не заменяет настройку. Для 1С типовые параметры задают исходя из объёма памяти сервера и числа пользователей. Ориентиры для выделенного сервера СУБД с 32 ГБ памяти (подбирайте под свою нагрузку):

Проверка простая: SHOW имя_параметра; для каждого. Если после установки значения оказались стандартными (например, shared_buffers в 128 МБ), вернитесь к сохранённой копии postgresql.conf и перенесите свои строки.

Что стоит проверить через неделю после обновления:

• 📊 время типичных операций: проведение документов, формирование тяжёлого отчёта;
• 🧾 размер базы и динамику его роста;
• 🐌 долгие запросы в журнале (параметр log_min_duration_statement покажет всё, что дольше заданного порога, скажем 5 секунд);
• 🧹 работу автовакуума: он не должен постоянно «догонять».

Если картина стала лучше, зафиксируйте версию сборки и дату в документации по серверу. Через год вы не вспомните, что и когда ставили.

Можно ли автоматизировать обновление

Можно, но с оговорками. Полностью автоматическое обновление СУБД на боевом сервере 1С — плохая идея: служба перезапустится в рабочее время, а пользователи потеряют сеанс.

Разумная схема:

• 🔔 автоматически только уведомление о выходе новой версии;
• 🧪 обновление сначала на тестовой копии сервера;
• 🛠️ боевой сервер — по расписанию в нерабочее окно, с предварительным бэкапом в том же скрипте;
• 📄 лог выполнения скрипта сохраняется и проверяется.

Простой пример скрипта-каркаса для Linux, который делает копию и только потом обновляет пакеты:

#!/bin/bash
set -e
BACKUP=/backup/pg_$(date +%F).sql.gz
sudo -u postgres pg_dumpall | gzip > "$BACKUP"
systemctl stop postgresql
apt-get install --only-upgrade имя-пакета-postgresql
systemctl start postgresql
sudo -u postgres psql -c "SELECT version();"

Проверьте, что скрипт не ломает рабочие соединения: службу сервера 1С в сценарии лучше останавливать явно.

Типичные ошибки при обновлении

Большинство проблем после обновления повторяется из раза в раз.

• ❌ Поставили обычный PostgreSQL поверх доработанного. Версия вроде совпала, а поведение изменилось. Проверяйте источник сборки.
• ❌ Перепутали мажорную и младшую версию. Между мажорными ветками каталог данных несовместим, нужен перенос.
• ❌ Не вернули настройки. После установки shared_buffers и work_mem стали стандартными, а база тормозит.
• ❌ Не пересобрали статистику. После переноса данных выполните ANALYZE, иначе планировщик работает вслепую.
• ❌ Обновили в рабочее время без остановки службы 1С.

Если после обновления всё равно медленно:

1. Выполните ANALYZE по базам.
2. Проверьте, применились ли ваши параметры в postgresql.conf (SHOW shared_buffers;).
3. Посмотрите журнал PostgreSQL на ошибки и предупреждения.
4. При необходимости откатитесь на прежнюю сборку: каталог данных и копия конфигурации у вас есть.

Откат младшей версии обычно проходит просто. Откат мажорной версии без резервной копии невозможен.

Частые вопросы