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

08007
2026년 05월 31일 | DBMS Error 가이드

이 글에서 다루는 내용

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

08007 transaction resolution unknown 는?

PostgreSQL 에러 코드 08007 transaction resolution unknown은 2단계 커밋(Two-Phase Commit, 2PC) 과정에서 트랜잭션의 최종 상태(커밋 또는 롤백 여부)를 결정할 수 없을 때 발생하는 에러입니다. 분산 트랜잭션 환경에서 PREPARE TRANSACTION 이후 네트워크 장애, 코디네이터 크래시, 또는 참여 노드 간의 통신 단절이 발생하면 해당 트랜잭션이 “미결(in-doubt)” 상태로 남게 됩니다. 이 상태에서 PostgreSQL은 트랜잭션을 커밋해야 할지 롤백해야 할지 독자적으로 판단할 수 없기 때문에, 외부 개입 없이는 자동으로 해결되지 않아 운영 환경에서 심각한 장애로 이어질 수 있습니다.

주요 발생 원인

1. 2단계 커밋 코디네이터(Coordinator) 장애

분산 트랜잭션에서 코디네이터 역할을 하는 미들웨어(예: Java의 JTA, Pgpool-II, 또는 커스텀 애플리케이션)가 PREPARE TRANSACTION을 실행한 이후 크래시되거나 네트워크 연결이 끊어지면, 참여 PostgreSQL 노드는 트랜잭션의 최종 결정을 통보받지 못합니다. 이 경우 pg_prepared_xacts 시스템 뷰에 해당 트랜잭션이 지속적으로 남아 있게 되고, 관련 잠금(lock)이 해제되지 않아 다른 트랜잭션이 블로킹되는 연쇄 장애가 발생할 수 있습니다.

2. 네트워크 파티션(Network Partition) 또는 타임아웃

분산 시스템에서 PREPARE TRANSACTION 이후 참여 노드들 간에 네트워크 파티션이 발생하거나, 코디네이터의 응답 타임아웃이 너무 짧게 설정된 경우 트랜잭션 결정 메시지가 전달되지 않을 수 있습니다. 특히 클라우드 환경이나 멀티 리전 구성에서는 일시적인 네트워크 지연만으로도 이 상황이 빈번하게 재현될 수 있으며, 운영자가 인지하지 못한 채 미결 트랜잭션이 누적되는 경우가 많습니다.

3. 애플리케이션의 잘못된 2PC 구현 또는 예외 처리 누락

PREPARE TRANSACTION을 명시적으로 사용하는 커스텀 애플리케이션에서 예외 처리 로직이 불완전할 경우, COMMIT PREPARED 또는 ROLLBACK PREPARED를 호출하지 않고 커넥션이 닫히는 상황이 발생합니다. JDBC, libpq 등을 직접 제어하는 코드에서 트랜잭션 ID 관리나 에러 핸들링이 제대로 구현되지 않으면, 데이터베이스 서버는 해당 트랜잭션의 의도를 알 수 없는 상태로 방치됩니다.

해결 방법

1단계: 현재 미결 트랜잭션 현황 파악

먼저 pg_prepared_xacts 뷰를 통해 현재 준비(prepared) 상태로 남아 있는 트랜잭션 목록을 확인합니다.

-- 미결 트랜잭션 전체 조회
SELECT 
    gid,
    prepared,
    owner,
    database,
    transaction,
    EXTRACT(EPOCH FROM (now() - prepared)) / 60 AS minutes_pending
FROM pg_prepared_xacts
ORDER BY prepared ASC;

오래된 미결 트랜잭션이 존재한다면(예: 수 분 이상 지속), 운영 환경에서 잠금 경합을 유발하고 있을 가능성이 높습니다.

2단계: 관련 잠금 현황 확인

미결 트랜잭션이 어떤 잠금을 보유하고 있는지 확인하여 영향 범위를 파악합니다.

-- 미결 트랜잭션의 잠금 정보 확인
SELECT 
    pxacts.gid,
    pxacts.prepared,
    pxacts.owner,
    locks.locktype,
    locks.relation::regclass AS locked_relation,
    locks.mode,
    locks.granted
FROM pg_prepared_xacts pxacts
JOIN pg_locks locks 
    ON locks.transactionid = pxacts.transaction
        OR locks.virtualtransaction = '-1/' || pxacts.transaction::text
ORDER BY pxacts.prepared;

3단계: 코디네이터와 협의하여 트랜잭션 결정

원칙적으로는 코디네이터 시스템(애플리케이션 서버 또는 미들웨어)의 트랜잭션 로그를 확인하여 해당 gid의 원래 의도가 커밋인지 롤백인지를 먼저 파악해야 합니다. 코디네이터 로그를 통해 의도를 확인한 뒤, 아래와 같이 처리합니다.

-- 코디네이터 로그 확인 후 커밋이 맞는 경우
COMMIT PREPARED 'your_transaction_gid_here';

-- 코디네이터 로그 확인 후 롤백이 맞는 경우
ROLLBACK PREPARED 'your_transaction_gid_here';

> ⚠️ 주의: COMMIT PREPARED 또는 ROLLBACK PREPARED는 슈퍼유저이거나 해당 트랜잭션의 소유자만 실행할 수 있습니다. 반드시 코디네이터의 의사결정 로그를 확인한 후 실행하세요.

4단계: 슈퍼유저로 강제 정리 (긴급 상황)

코디네이터 시스템이 복구 불가능하고 비즈니스적 판단에 의해 롤백이 안전한 경우, 슈퍼유저 권한으로 강제 롤백할 수 있습니다.

-- 슈퍼유저로 강제 롤백 (긴급 시에만 사용)
-- 먼저 gid 목록을 확인하고 하나씩 처리
DO $$
DECLARE
    r RECORD;
BEGIN
    FOR r IN 
        SELECT gid 
        FROM pg_prepared_xacts 
        WHERE prepared < now() - INTERVAL '30 minutes'
          AND database = current_database()
    LOOP
        RAISE NOTICE '롤백 처리 중: %', r.gid;
        EXECUTE 'ROLLBACK PREPARED ' || quote_literal(r.gid);
    END LOOP;
END;
$$;

5단계: 정리 후 상태 검증

-- 처리 후 미결 트랜잭션이 없는지 최종 확인
SELECT COUNT(*) AS remaining_prepared_transactions
FROM pg_prepared_xacts
WHERE database = current_database();

-- 잔여 잠금 확인
SELECT pid, usename, application_name, wait_event_type, wait_event, state, query
FROM pg_stat_activity
WHERE wait_event_type = 'Lock'
ORDER BY state_change;

예방 방법

1. 미결 트랜잭션 모니터링 자동화 및 알림 설정

pg_prepared_xacts를 주기적으로 모니터링하여 일정 시간(예: 5분) 이상 해결되지 않은 준비 트랜잭션이 존재할 경우 즉시 알림을 받을 수 있도록 설정합니다. Prometheus + postgres_exporter를 사용하는 환경이라면 아래와 같은 쿼리를 커스텀 메트릭으로 등록하거나, pg_cron을 이용한 자동 감사 로그를 구성할 수 있습니다.

-- pg_cron을 이용한 주기적 감사 로그 (예: 매 5분마다 실행)
-- pg_cron 확장이 설치된 환경에서 사용
SELECT cron.schedule(
    'check_prepared_xacts',
    '*/5 * * * *',
    $$
    INSERT INTO dba_audit.prepared_xact_log (gid, prepared, owner, database, logged_at)
    SELECT gid, prepared, owner, database, now()
    FROM pg_prepared_xacts
    WHERE prepared < now() - INTERVAL '5 minutes';
    $$
);

-- 모니터링용 뷰 생성
CREATE OR REPLACE VIEW dba_monitor.v_stale_prepared_xacts AS
SELECT 
    gid,
    prepared,
    owner,
    database,
    EXTRACT(EPOCH FROM (now() - prepared)) / 60 AS minutes_pending,
    CASE 
        WHEN prepared < now() - INTERVAL '30 minutes' THEN 'CRITICAL'
        WHEN prepared < now() - INTERVAL '10 minutes' THEN 'WARNING'
        ELSE 'INFO'
    END AS severity
FROM pg_prepared_xacts
ORDER BY prepared ASC;

2. max_prepared_transactions 파라미터 및 2PC 사용 정책 명문화

실제로 2단계 커밋을 사용하지 않는 서비스라면, postgresql.conf에서 max_prepared_transactions = 0으로 설정하여 PREPARE TRANSACTION 자체를 비활성화하는 것이 가장 안전한 예방책입니다. 2PC를 반드시 사용해야 하는 경우에는 코디네이터 장애 시 자동 복구 절차(예: 코디네이터 재시작 후 미결 트랜잭션 재처리 로직)를 문서화하고, 트랜잭션 GID 네이밍 규칙을 표준화하여 추적성을 확보해야 합니다.

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

-- 2PC 미사용 환경에서는 0으로 설정 권장 (postgresql.conf 수정 후 재시작 필요)
-- max_prepared_transactions = 0

-- GID 네이밍 규칙 예시: {서비스명}_{코디네이터ID}_{타임스탬프}
-- 'payment-svc_coord01_20240115T143022Z'
-- 이렇게 하면 어떤 서비스의 어떤 코디네이터가 생성한 트랜잭션인지 즉시 파악 가능