Обновление сборки PostgreSQL для 1С: минорный патч и переход на новую версию

Чтобы установить патч PostgreSQL для 1С, остановите сервер 1С, сделайте резервную копию через pg_dump, поставьте новую сборку той же мажорной версии поверх старой и запустите службы. Если меняется мажорная версия (например, 14 на 16), простой установки поверх мало: нужен pg_upgrade или выгрузка и загрузка баз.

Главная ловушка — поставить «обычный» PostgreSQL из репозитория ОС. Базы 1С на нём не откроются: в ванильной сборке нет типов и расширений, которые нужны платформе. Поэтому перед любым обновлением проверяйте, от какого поставщика сборка и есть ли в ней расширения 1С.

Чем сборка PostgreSQL для 1С отличается от обычной

1С работает только с PostgreSQL, к которому применён набор патчей. Эти патчи добавляют то, чего нет в стандартной поставке:

• 🔤 тип mchar/mvarchar — строки без учёта регистра в стиле MS SQL, на них построены таблицы 1С;
• 🔎 расширение fulltextsearch и словари для полнотекстового поиска;
• ⚡ fasttrun — быстрая очистка временных таблиц, которые платформа создаёт постоянно;
• 📊 online_analyze и plantuner — обновление статистики временных таблиц и подсказки планировщику.

Готовые сборки выпускают две стороны: фирма 1С (дистрибутивы и архив патчей для самостоятельной сборки) и компания Postgres Professional (бесплатная сборка «PostgreSQL для 1С» с репозиториями под популярные дистрибутивы Linux и инсталлятором под Windows). Обе подходят. Главное — не смешивать их в рамках одного обновления без необходимости: каталоги установки, имена служб и пакетов у них разные.

Совместимость версий 1С и PostgreSQL: что проверить до установки патча

Сначала узнайте, что стоит сейчас. В psql или pgAdmin выполните:

SELECT version();
SELECT name, default_version, installed_version
FROM pg_available_extensions
WHERE name IN ('mchar', 'fulltextsearch', 'fasttrun', 'online_analyze', 'plantuner');

Если запрос вернул строки с этими расширениями — у вас сборка для 1С. Пустой результат означает ванильный PostgreSQL, и это уже отдельная проблема.

Дальше сверьте три вещи:

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

Если нужен переход на новую мажорную версию, а платформа её ещё не знает, порядок такой: сначала обновить платформу 1С на сервере и клиентах до номера не ниже требуемого, потом PostgreSQL.

Подготовка к установке патча PostgreSQL

Обновление СУБД обрывает все сеансы 1С. Планируйте его на нерабочее время и предупредите пользователей заранее.

Резервные копии делаются так:

# каждая база отдельно, сжатый формат
pg_dump -U postgres -Fc -f /backup/buh_$(date +%F).dump buh

# роли, пароли, табличные пространства
pg_dumpall -U postgres --globals-only -f /backup/globals_$(date +%F).sql

На Windows те же команды запускаются из каталога bin установленного PostgreSQL. Дополнительно можно выгрузить каждую базу в .dt через Конфигуратор: Администрирование → Выгрузить информационную базу. Это страховка на случай, если восстанавливать придётся на другом сервере или другой СУБД.

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

Установка патча PostgreSQL внутри одной мажорной версии

Минорное обновление (например, 15.6 → 15.8) не меняет формат каталога данных. Бинарные файлы заменяются, данные остаются на месте, дамп и восстановление не нужны.

На Windows

1. Остановите службу сервера 1С — «Агент сервера 1С:Предприятия 8.3». Команда в PowerShell от администратора: Get-Service *1C* покажет точное имя, затем Stop-Service "<имя>".
2. Остановите службу PostgreSQL: Get-Service *postgres*, затем Stop-Service.
3. Запустите инсталлятор новой сборки. Укажите тот же каталог установки и тот же каталог данных, что у старой версии. Порт оставьте прежним (по умолчанию 5432).
4. После установки запустите службу PostgreSQL, затем службу 1С.
5. Выполните SELECT version(); и убедитесь, что номер сменился.

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

На Linux (Debian, Ubuntu)

При установке из репозитория поставщика сборки патч ставится штатным обновлением пакетов:

# узнать точные имена установленных пакетов
apt list --installed | grep -i postgres

# остановить сервер 1С (имя юнита зависит от версии платформы)
systemctl list-units | grep -i srv1cv8
sudo systemctl stop <имя юнита сервера 1С>

# обновить только пакеты PostgreSQL
sudo apt update
sudo apt install --only-upgrade <имена пакетов из первой команды>

sudo systemctl start <имя юнита сервера 1С>

Пакетный менеджер сам перезапустит службу PostgreSQL. На RPM-системах логика та же через dnf upgrade <пакеты>.

Если сборка ставилась из .deb или .rpm, скачанных вручную, установите новые файлы теми же командами: sudo dpkg -i *.deb или sudo dnf install ./*.rpm.

Переход на новую мажорную версию PostgreSQL

Между мажорными версиями формат данных разный. Новый сервер старый каталог не прочитает. Вариантов два:

Порядок для pg_upgrade на Linux:

1. Установите новую мажорную сборку для 1С рядом со старой. Обычно она создаёт свой кластер на порту 5433 — это нормально.
2. Убедитесь, что в новой сборке есть те же расширения (запрос из раздела про совместимость).
3. Остановите сервер 1С и оба кластера PostgreSQL.
4. Запустите проверку от пользователя postgres:

/путь/к/новой/bin/pg_upgrade \
  -b /путь/к/старой/bin  -B /путь/к/новой/bin \
  -d /старый/каталог/данных -D /новый/каталог/данных \
  --check

5. Если проверка прошла, повторите команду без --check.
6. Перенесите свои настройки из старого postgresql.conf и pg_hba.conf вручную: pg_upgrade их не копирует.
7. Поменяйте порты местами (новый кластер — 5432), запустите его и сервер 1С.
8. Соберите статистику, иначе первые часы 1С будет работать медленно: vacuumdb -U postgres --all --analyze-in-stages.

Старый кластер не удаляйте, пока пользователи не отработают на новом хотя бы пару дней.

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

Сначала убедитесь, что расширения в базах соответствуют новым бинарникам. Сравните колонки default_version и installed_version из запроса выше. Если они расходятся, выполните в каждой базе 1С:

ALTER EXTENSION mchar UPDATE;

(и аналогично для остальных расширений из списка, если версия отличается).

Затем пройдитесь по параметрам postgresql.conf. Ориентиры для выделенного сервера под 1С:

Числа — стартовая точка. Точная настройка зависит от объёма ОЗУ, числа пользователей и того, делит ли PostgreSQL сервер с 1С.

Финальная проверка:

1. Откройте каждую базу в режиме 1С:Предприятие под пользователем с полными правами.
2. Сформируйте тяжёлый отчёт, который раньше выполнялся за известное время, и сравните.
3. В консоли кластера 1С проверьте, что регламентные задания запускаются без ошибок.
4. Посмотрите журнал PostgreSQL на предмет ERROR и FATAL за последний час.

Как автоматизировать установку патчей

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

Пример скрипта для Linux, который выполняет подготовку, обновление и проверку за один запуск:

#!/bin/bash
set -e
SRV1C="<имя юнита сервера 1С>"
PKGS="<пакеты PostgreSQL через пробел>"
BK=/backup/$(date +%F)
mkdir -p "$BK"

# 1. резервные копии всех баз, кроме служебных
for db in $(psql -U postgres -Atc "SELECT datname FROM pg_database WHERE datistemplate = false AND datname <> 'postgres'"); do
  pg_dump -U postgres -Fc -f "$BK/$db.dump" "$db"
  pg_restore -l "$BK/$db.dump" > /dev/null
done
pg_dumpall -U postgres --globals-only -f "$BK/globals.sql"

# 2. обновление
systemctl stop "$SRV1C"
apt-mark unhold $PKGS
apt-get update && apt-get install -y --only-upgrade $PKGS
apt-mark hold $PKGS
systemctl start "$SRV1C"

# 3. контроль
psql -U postgres -Atc "SELECT version();"

Строка с pg_restore -l прерывает скрипт, если дамп битый, и до обновления дело не дойдёт.

Что ещё стоит автоматизировать:

• 🔔 проверку выхода новых сборок — сравнение версии в репозитории с установленной (apt list --upgradable) с уведомлением администратору;
• 🧪 разворачивание ночного дампа на тестовом сервере и прогон обновления сначала там;
• 🚫 исключение пакетов PostgreSQL из unattended-upgrades, если автообновление ОС включено.

На Windows ту же последовательность собирают в PowerShell: Stop-Service, pg_dump в цикле, тихая установка дистрибутива , Start-Service. Ключи тихой установки у инсталляторов разных поставщиков отличаются — смотрите их в справке конкретного дистрибутива.

Ошибки при установке патча и что с ними делать

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