Заметка на память - как не надо завершать процесс в PostgreSQL⁠⁠

Иногда случается ситуация : нужно завершить долгий SQL запрос (кильнуть сессию).

Стандартный способ, рекомендованный в документации :
select pg_terminate_backend( pid );

Однако, иногда, если запрос очень долгий , даже после прерывания процесса, pid всё равно еще остается в результате запроса select ... from pg_stat_activity ;

И в этой ситуации может возникнуть соблазн "kill -9 pid"
Чтобы побыстрее ...

После выполнения kill , кластер PostgreSQL аварийно перезапустится , со всеми вытекающими последствиями .
Быстрее - не получится .

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

P.S. Ну и как обычно , мнение ИИ. Страшилка о 'kill -9" от DeepSeek:

После выполнения команды `kill -9` для процесса PostgreSQL, выполняющего долгий запрос, возникают следующие последствия:

### 1. **Прерывание транзакции**
- Транзакция, связанная с убитым процессом, **не будет завершена корректно**. Поскольку `SIGKILL` (сигнал 9) нельзя перехватить или обработать, PostgreSQL не успевает выполнить откат (`ROLLBACK`) транзакции. Это может привести к:
- **Незавершенным изменениям данных**: Если транзакция выполняла модификацию данных (INSERT/UPDATE/DELETE), изменения останутся в состоянии "под вопросом" до восстановления.
- **Блокировкам (locks)**: Ресурсы (строки, таблицы), заблокированные транзакцией, могут остаться занятыми до очистки процесса.

### 2. **Автоматическое восстановление PostgreSQL**
- PostgreSQL обнаруживает аварийное завершение процесса и автоматически выполняет:
- **Очистку блокировок**: Все удерживаемые процессом блокировки освобождаются.
- **Откат транзакции**: Незавершенная транзакция откатывается с помощью механизма восстановления на основе **WAL (Write-Ahead Logging)**. Это гарантирует целостность данных, но может занять время, особенно если транзакция была крупной.

### 3. **Влияние на производительность**
- **Долгое восстановление**: Если убитый процесс работал с большим объемом данных, откат транзакции через WAL может задержать другие операции.
- **Возможные задержки**: Другие сессии, ожидавшие блокировок от убитого процесса, получат доступ к ресурсам только после завершения восстановления.

### 4. **Ошибки в клиентских приложениях**
- Клиент, инициировавший запрос, получит ошибку соединения (например, `connection terminated unexpectedly`). Приложение должно быть готово к таким сценариям (повторные попытки, обработка исключений).

### 5. **Риск для репликации (если используется)**
- В режимах синхронной репликации аварийное завершение процесса может временно нарушить синхронизацию данных между primary и standby-серверами. Однако механизм WAL гарантирует восстановление согласованности.

### 6. **Журналирование (логи)**
- В логах PostgreSQL появится запись об аварийном завершении процесса, например:
```
FATAL: terminating connection due to administrator command
LOG: server process (PID 12345) was terminated by signal 9: Killed
LOG: aborting any active transactions
```

---

### Рекомендации:
1. **Избегайте `kill -9`**, если это возможно. Используйте `pg_cancel_backend()` или `pg_terminate_backend()` для безопасного завершения запросов.
2. Для долгих транзакций настройте `statement_timeout` или `idle_in_transaction_session_timeout`.
3. Мониторьте активные транзакции через `pg_stat_activity`.

**Итог**: `kill -9` не повредит данные благодаря WAL, но может вызвать временные задержки и требует времени на автоматическое восстановление.