PostgreSQL 08007 오류 원인과 해결 방법 완벽 가이드

08007
2026년 10월 08일 | DBMS Error 가이드

이 글에서 다루는 내용

08007 에러의 원인 분석, 해결 SQL, 예방 방법을 실무 관점에서 정리합니다.

08007 transaction resolution unknown 는?

PostgreSQL 에러 코드 08007 transaction resolution unknown은 분산 트랜잭션(2PC, Two-Phase Commit) 환경에서 트랜잭션의 최종 커밋 또는 롤백 여부를 시스템이 확정할 수 없을 때 발생하는 에러입니다. 주로 네트워크 단절, 코디네이터 노드 장애, 또는 prepared transaction 처리 중 예기치 않은 서버 재시작이 발생했을 때 나타납니다. 이 에러는 데이터 일관성과 직결되기 때문에 즉각적인 확인과 조치가 필요한 심각한 상황을 의미합니다.

주요 발생 원인

1. Two-Phase Commit(2PC) 도중 코디네이터 장애

분산 트랜잭션에서 PREPARE TRANSACTION 명령 이후 코디네이터(애플리케이션 서버 또는 미들웨어)가 장애로 중단되면, 해당 트랜잭션은 pg_prepared_xacts 뷰에 남아 있지만 커밋도 롤백도 되지 않은 미결 상태(in-doubt transaction)가 됩니다. PostgreSQL은 이 트랜잭션의 최종 상태를 스스로 결정할 수 없기 때문에 08007 에러를 반환합니다. 코디네이터가 복구되지 않으면 DBA가 직접 수동으로 해결해야 합니다.

2. 네트워크 단절로 인한 응답 유실

PREPARE TRANSACTION 이후 코디네이터가 각 참여 노드에 COMMIT PREPARED 또는 ROLLBACK PREPARED 명령을 전송하는 도중 네트워크 단절이 발생하면, 일부 노드는 커밋이 완료되고 일부 노드는 미결 상태로 남게 됩니다. 이로 인해 클라이언트는 트랜잭션 결과를 알 수 없게 되며, 에러 코드 08007이 발생합니다. 이 상황은 특히 WAN 환경이나 클라우드 기반 분산 DB 아키텍처에서 빈번하게 나타납니다.

3. 서버 비정상 종료 및 재시작

PostgreSQL 서버가 PREPARE TRANSACTION 완료 후, COMMIT PREPARED 처리 전에 비정상 종료(OOM Killer, 하드웨어 장애 등)되면 WAL(Write-Ahead Log)에는 prepare 레코드가 남지만 commit 레코드가 없는 상태가 됩니다. 재시작 이후 복구 과정에서 해당 트랜잭션의 최종 상태를 확정할 수 없어 08007 에러가 발생할 수 있습니다. 이 경우 pg_prepared_xacts를 반드시 확인해야 합니다.

해결 방법

Step 1. 미결 트랜잭션 현황 파악

가장 먼저 pg_prepared_xacts 시스템 뷰를 조회하여 현재 prepared 상태로 남아 있는 트랜잭션을 확인합니다.

-- 현재 미결(prepared) 트랜잭션 전체 조회
SELECT
    gid,
    prepared,
    owner,
    database,
    transaction
FROM pg_prepared_xacts
ORDER BY prepared ASC;

prepared 컬럼의 시각이 오래된 트랜잭션일수록 문제가 된 트랜잭션일 가능성이 높습니다.

Step 2. 트랜잭션 이력 추적 (로그 확인)

PostgreSQL 로그와 애플리케이션 로그에서 해당 gid(global transaction id)를 검색하여 원래 의도가 커밋이었는지 롤백이었는지 확인합니다.

-- 특정 gid의 prepared 트랜잭션 상세 확인
SELECT *
FROM pg_prepared_xacts
WHERE gid = 'your_global_transaction_id';

Step 3-A. 커밋으로 해결 (원래 의도가 커밋인 경우)

코디네이터 로그나 애플리케이션 로그를 통해 해당 트랜잭션이 커밋되어야 함이 확인된 경우, COMMIT PREPARED를 실행합니다.

-- 미결 트랜잭션 커밋 처리
COMMIT PREPARED 'your_global_transaction_id';

> 주의: 슈퍼유저 또는 해당 트랜잭션의 owner만 실행 가능합니다.

Step 3-B. 롤백으로 해결 (원래 의도가 롤백이거나 불확실한 경우)

트랜잭션의 원래 의도를 확인할 수 없거나 롤백이 안전하다고 판단되는 경우, ROLLBACK PREPARED를 실행합니다.

-- 미결 트랜잭션 롤백 처리
ROLLBACK PREPARED 'your_global_transaction_id';

Step 4. 오래된 미결 트랜잭션 일괄 정리 스크립트

운영 환경에서 일정 시간(예: 1시간) 이상 경과한 미결 트랜잭션을 자동으로 롤백하는 스크립트입니다.

-- 1시간 이상 경과한 prepared 트랜잭션 자동 롤백 (주의해서 사용)
DO $$
DECLARE
    r RECORD;
BEGIN
    FOR r IN
        SELECT gid
        FROM pg_prepared_xacts
        WHERE prepared < NOW() - INTERVAL '1 hour'
    LOOP
        RAISE NOTICE 'Rolling back prepared transaction: %', r.gid;
        EXECUTE 'ROLLBACK PREPARED ' || quote_literal(r.gid);
    END LOOP;
END;
$$;

> 경고: 이 스크립트는 반드시 DBA가 트랜잭션 의도를 확인한 후 실행해야 합니다. 무분별한 사용은 데이터 손실을 초래할 수 있습니다.

Step 5. max_prepared_transactions 설정 확인

max_prepared_transactions가 0으로 설정되어 있으면 2PC 자체가 비활성화되므로, 분산 트랜잭션이 필요한 환경에서는 적절한 값을 설정해야 합니다.

-- 현재 max_prepared_transactions 설정 확인
SHOW max_prepared_transactions;

-- postgresql.conf에서 설정 (서버 재시작 필요)
-- max_prepared_transactions = 100

-- 설정 변경 후 확인
SELECT name, setting, unit, context
FROM pg_settings
WHERE name = 'max_prepared_transactions';

예방 방법

1. 모니터링 알림 설정으로 미결 트랜잭션 조기 감지

pg_prepared_xacts를 주기적으로 폴링하여 일정 시간 이상 경과한 prepared 트랜잭션이 존재할 경우 즉시 알림을 발송하는 모니터링 쿼리를 구성합니다. Zabbix, Prometheus, Datadog 등 모니터링 도구와 연동하여 임계값(예: 10분)을 초과하면 PagerDuty나 Slack으로 알림을 보내도록 설정하면 장애 확산을 막을 수 있습니다.

-- 모니터링 쿼리 예시: 10분 이상 경과한 미결 트랜잭션 수 반환
SELECT COUNT(*) AS stale_prepared_count
FROM pg_prepared_xacts
WHERE prepared < NOW() - INTERVAL '10 minutes';

2. 코디네이터 고가용성(HA) 구성 및 트랜잭션 로그 보관

2PC 코디네이터(미들웨어, 애플리케이션 서버)에 HA 구성을 적용하여 단일 장애점(SPOF)을 제거합니다. 또한 모든 PREPARE TRANSACTION의 gid와 의도(커밋/롤백)를 별도의 영구 스토리지(DB 테이블 또는 외부 트랜잭션 로그)에 기록해두면, 장애 복구 시 어떤 트랜잭션을 어떻게 처리해야 하는지 명확히 판단할 수 있어 08007 에러 상황을 신속하게 해결할 수 있습니다.