С чего начать

Откройте лог установщика. Под Windows это bitrock_installer.log в каталоге %TEMP% – в нем записана точная строка сбоя initdb. На Linux смотрите вывод инициализации и логи в /var/log/postgresql/:

%TEMP%\bitrock_installer.log

Что проверить

1. Каталог данных должен быть пустым. initdb отказывается инициализировать непустую директорию, чтобы не затереть существующие данные. Если PostgreSQL уже ставился по этому пути, очистите или удалите старый каталог данных (убедившись, что в нем нет нужных баз).
2. Проверьте права на каталог данных. Под Windows у служебной учетной записи должен быть полный доступ к папке – частый сбой возникает на внешних и несистемных дисках; права выдаются на вкладке «Безопасность» в свойствах папки. Под Linux initdb запускается от пользователя postgres, а не от root:

   sudo -u postgres initdb -D /var/lib/pgsql/data

3. Убедитесь, что порт 5432 свободен. Если его занял другой экземпляр PostgreSQL, Docker или иная служба, инициализация и запуск завершаются ошибкой – задайте свободный порт при установке.
4. Только Windows: проверьте службу «Вторичный вход в систему» (Secondary Logon) – установщик выполняет инициализацию через initcluster.vbs в отдельном контексте пользователя. Также проверьте ассоциацию .vbs в реестре (HKEY_CLASSES_ROOT\.vbs = VBSFile) и что не отключен Windows Script Host.

Ручная инициализация

Если установщик стабильно не проходит этот шаг, откажитесь от автоматической инициализации и выполните initdb вручную из каталога bin, указав пустой каталог данных и локаль. При установке под 1С задается локаль Russian_Russia.1251 с кодировкой UTF8.

 

Где смотреть причину

Откройте лог установщика – он лежит в %TEMP% под именем bitrock_installer.log (установщики PostgreSQL работают на движке BitRock). В нем обычно указана конкретная причина сбоя, и дальнейшие шаги стоит сверять именно с ним:

%TEMP%\bitrock_installer.log

Что проверить

1. Запускайте установщик от имени администратора – через правый клик «Запуск от имени администратора». Нехватка прав на запись во временный каталог – самая частая причина.
2. Проверьте системную переменную TEMP: путь должен существовать, быть доступен на запись и не содержать кириллицы. Очистите папку %TEMP% от файлов прошлых неудачных попыток.
3. Временно отключите антивирус – экраны реального времени часто блокируют создание временных файлов.
4. Проверьте ассоциацию файлов .vbs. Установщик вызывает VBS-скрипты, и если расширение перехвачено сторонним приложением (например, редактором кода) или отключен Windows Script Host, инициализация падает. В реестре HKEY_CLASSES_ROOT\.vbs значение по умолчанию должно быть VBSFile.
5. Убедитесь, что запущена служба «Вторичный вход в систему» (Secondary Logon) – установщик использует переключение контекста пользователя, и при остановленной службе установка может прерываться.

Запасной вариант

Если ошибка повторяется, откажитесь при установке от автоматической инициализации кластера и выполните initdb вручную позже. Для связки с 1С важно задать корректную локаль – Russian_Russia.1251 с кодировкой UTF8. Перед повторной установкой проверьте наличие пакетов Microsoft Visual C++ Redistributable, от которых зависят современные версии PostgreSQL.

Как определить путь

1. Запросите пути прямо из базы – значения указывают на активные файлы, которые сейчас использует сервер:

   SHOW config_file;
   
   SHOW hba_file;
   
   SHOW data_directory;

2. config_file – путь к postgresql.conf, hba_file – к pg_hba.conf(правила аутентификации). Оба обычно лежат в каталоге данных, но в ряде дистрибутивов вынесены отдельно.

Типовое расположение

В сборках Debian и Ubuntu конфиг вынесен в /etc/postgresql/<версия>/<кластер>/postgresql.conf. В сборках на базе RHEL и при установке из исходников он находится в каталоге данных – например, /var/lib/pgsql/<версия>/data/postgresql.conf. В Windows это подкаталог data каталога установки, обычно C:\Program Files\PostgreSQL\<версия>\data.

Дополнительные файлы конфигурации

Часть настроек может быть вынесена в отдельные файлы через директиву include, а параметры, измененные командой ALTER SYSTEM, пишутся не в postgresql.conf, а в postgresql.auto.conf в каталоге данных. Проверить, откуда пришло конкретное значение, можно через представление pg_settings (столбец sourcefile).

Как читать план

1. Смотрите на каждый узел пару значений вида actual time=0.05..12.4 rows=1000 loops=1. Первое число – время до первой строки, второе – время до последней; оба указаны на одно выполнение узла.
2. Учитывайте loops: если узел выполнялся многократно (вложенный цикл), фактическое суммарное время – это время на проход, умноженное на число проходов. Итоговые строки – rows × loops.
3. Сравните оценку и факт. Планировщик пишет ожидаемое число строк (rows= в блоке оценки), ANALYZE – фактическое. Кратное расхождение – главный признак проблемы: устаревшая статистика или неверная оценка селективности ведут к неоптимальному плану.

На что смотреть

Строка Rows Removed by Filter показывает объем прочитанного и отброшенного – кандидат на индекс. Переход Index Scan → Seq Scan на большой таблице часто говорит об устаревшей статистике. Добавьте BUFFERS, чтобы увидеть чтение из кеша против диска:

EXPLAIN (ANALYZE, BUFFERS) SELECT id, name FROM orders WHERE status = 'new';

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

Как настроить автоматическую очистку

1. Включите ротацию с перезаписью в postgresql.conf. Циклический шаблон имени плюс усечение при ротации дают ограниченный набор файлов, которые перезаписываются по кругу:

   log_filename = 'postgresql-%a.log'
   
   log_truncate_on_rotation = on
   
   log_rotation_age = 1d
   
   log_rotation_size = 0

2. Примените изменения без перезапуска:

   SELECT pg_reload_conf();

Важные нюансы

Усечение при log_truncate_on_rotation = on срабатывает только при ротации по времени – при перезапуске сервера и ротации по размеру файл дописывается, а не обнуляется. Шаблон %a (день недели) хранит логи за 7 суток и перезаписывает их на следующей неделе; для другого срока меняется маска имени. Если logging_collector = off и вывод идет в syslog или systemd, очисткой управляет система (logrotate, journald), а не PostgreSQL.

Частые причины

• Завышенный work_mem при большом числе параллельных запросов: каждая сортировка и хеш берут память отдельно.
• Тяжелый запрос с крупными сортировками, хешами или агрегацией по большому объему.
• Нехватка физической памяти на сервере или активное вытеснение в swap.
• Сообщение out of shared memory – превышен лимит блокировок, заданный max_locks_per_transaction (транзакция затрагивает слишком много объектов).

Как исправить ошибку 53200

1. Определите по тексту сообщения, какой это случай – нехватка RAM (out of memory) или блокировок (out of shared memory).
2. При out of memory снизьте work_mem, чтобы ограничить расход памяти на операцию (можно временно для сессии):

   SET work_mem = '64MB';

3. Найдите запрос, вызывающий всплеск потребления, и оцените его план:

   EXPLAIN ANALYZE SELECT ...;

4. При out of shared memory увеличьте лимит блокировок в postgresql.conf – изменение требует перезапуска сервера:

   max_locks_per_transaction = 128

5. Проверьте общий расход памяти на уровне ОС (free -m, top); при системном OOM процесс может быть завершен ядром, после чего сервер уходит в восстановление.

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

Как снять блокировку

1. Отмените активный запрос блокирующей сессии, не разрывая соединение – самый мягкий способ:

   SELECT pg_cancel_backend(12345);

2. Если запрос не отменяется или сессия висит в состоянии idle in transaction, завершите соединение целиком:

   SELECT pg_terminate_backend(12345);

3. Число 12345 – это pid удерживающего процесса. Определить его можно функцией pg_blocking_pid, передав ей номер ожидающей сессии:

   SELECT pg_blocking_pids(67890);

На что обратить внимание

pg_cancel_backend прерывает только текущий запрос, pg_terminate_backend разрывает всю сессию – ее незавершенная транзакция откатывается. Для выполнения нужны права суперпользователя, роль-владелец сессии или членство в роли pg_signal_backend. Причина зависшей блокировки (например, оставленная открытой транзакция в приложении) при этом не устраняется – завершение сессии снимает следствие, а не источник.

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

Частые причины

• Значение max_connections слишком мало для реальной нагрузки.
• Приложение не закрывает соединения или работает без пула – коннекты копятся.
• Множество сессий в состоянии idle in transaction удерживают слоты.
• Резкий рост числа воркеров или экземпляров приложения.

Как исправить ошибку 53300

1. Посмотрите текущие подключения и их состояние:

   SELECT count(*), state FROM pg_stat_activity GROUP BY state;

2. Найдите и при необходимости завершите зависшие сессии idle in transaction:

   SELECT pid, state, query_start FROM pg_stat_activity WHERE state = 'idle in transaction';

3. Поднимите лимит в postgresql.conf – изменение max_connections требует перезапуска сервера:

   max_connections = 200

4. Устойчивое решение при высокой нагрузке – пул соединений (PgBouncer) вместо простого повышения лимита: каждое подключение расходует память, и рост max_connections не бесплатен.

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

В Linux расположение логов зависит от дистрибутива и настройки сбора. В сборках Debian и Ubuntu файлы по умолчанию лежат в /var/log/postgresql/, в сборках на базе RHEL – в подкаталоге log внутри каталога данных. Если сбор логов выключен, вывод перехватывает systemd.

Как определить расположение

1. Запросите активные значения прямо из базы:

   SHOW logging_collector;
   
   SHOW log_directory;
   
   SHOW data_directory;

2. При logging_collector = on собранные логи находятся в log_directory: относительный путь отсчитывается от каталога данных, абсолютный используется как есть.
3. При logging_collector = off вывод идет в systemd. Имя юнита зависит от дистрибутива – в RHEL это postgresql, в Debian и Ubuntu юнит именуется по кластеру:

   journalctl -u postgresql@16-main

4. Для чтения активного файла в реальном времени используйте стандартные средства:

   tail -f /var/log/postgresql/postgresql-16-main.log

Что учесть

Каталог с логами принадлежит пользователю postgres, поэтому для доступа нужны его права или sudo. Файлы подчиняются ротации (штатной или через logrotate), поэтому старые записи со временем архивируются или удаляются.

Логи в файловой системе подчиняются ротации и очищаются при переустановке кластера – тогда, когда нужно восстановить хронологию инцидента, их часто уже нет. PGLens накапливает детальную статистику работы вашей СУБД в отдельной базе, поэтому историческая динамика нагрузки и аннотации событий остаются доступны и после удаления файлов.

Частые причины

• Тип столбца в INSERT или UPDATE не совпадает с типом значения и неявное приведение недоступно.
• Функция объявлена с RETURNS одного типа, а фактически возвращает другой.
• Ветви CASE или элементы UNION возвращают разные, несовместимые типы.
• В условии WHERE сравниваются несопоставимые типы (например, boolean и integer).
• Тип управляющего значения не соответствует объявлению (WHEN в CASE, аргумент условия).

Как исправить ошибку 42804

1. Определите проблемное место по тексту ошибки – PostgreSQL называет ожидаемый и полученный тип (column is of type integer but expression is of type text).
2. Приведите значение к нужному типу явным преобразованием:

   UPDATE orders SET amount = total_text::numeric WHERE id = 1;

3. Согласуйте типы в ветвях выражения – все ветви CASE и все части UNION должны возвращать один тип:

   SELECT id::text FROM a UNION ALL SELECT code::text FROM b;

4. При несовпадении типа возврата функции исправьте объявление RETURNS или приведите итоговое значение внутри функции.