• В технологическом журнале 1С или логах PostgreSQL фиксируется ошибка ERROR: 25P01: no active sql transaction или предупреждение WARNING: there is no transaction in progress.
• Сбой выполнения транзакционных цепочек в прикладном коде при попытке выполнить COMMIT или ROLLBACK.
• Аварийный разрыв сессий при работе через PgBouncer в режиме pool_mode = statement.
• В 1С:Предприятие транзакция завершается с ошибкой «В этой транзакции уже происходили ошибки» либо «Ошибка блокировки транзакции».

1. Анализ журнала PostgreSQL

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

log_statement = 'all'
log_min_messages = 'warning'
log_line_prefix = '%m [%p] %q%u@%d client=%h '

Перечитайте конфигурацию:

SELECT pg_reload_conf();

2. Проверка режима работы PgBouncer / Odyssey

Если используется пул соединений, убедитесь, что для приложений с длительными транзакциями (например, 1С:Предприятие или фреймворки с ручным управлением транзакциями) установлен режим пула transaction или session, но ни в коем случае не statement:

# /etc/pgbouncer/pgbouncer.ini
[databases]
enterprise_db = host=127.0.0.1 port=5432 dbname=enterprise_db pool_mode=transaction

[pgbouncer]
pool_mode = transaction
server_reset_query = DISCARD ALL

3. Корректировка логики в коде 1С / SQL-скриптах

Ошибка возникает, когда клиент посылает COMMIT/ROLLBACK без предварительного открытия блока BEGIN, либо после того, как сервер автоматически закрыл транзакцию по таймауту:

-- Некорректно (вызовет 25P01 при повторном завершении):
COMMIT;

-- Корректный паттерн в SQL:
DO $$
BEGIN
    -- Логика обработки
END $$;

4. Проверка таймаутов транзакций на стороне СУБД

Если фоновые процессы 1С долго удерживают транзакцию в состоянии ожидания, сервер может принудительно прервать ее по таймауту:

ALTER SYSTEM SET idle_in_transaction_session_timeout = '60s';
ALTER SYSTEM SET statement_timeout = '120s';
SELECT pg_reload_conf();