Windows 환경에서 PostgreSQL 서비스가 ‘백그라운드로 뜨는 것처럼 보이는’ 이유
– pg_ctl runservice, SCM 타임아웃, 그리고 느린 OS 부팅의 상관관계
1. 문제 현상
onTune V4 (Windows Server 환경)에서 다음과 같은 현상이 발생했다.
- 서버 재부팅 후
- services.msc 에서 onTune_DB 서비스는 정상적으로 올라오지 않았는데
- Task Manager 에는 postgres.exe 프로세스만 다수 실행 중
- 서비스 Stop 버튼은 동작하지 않음
- 결국 수동으로 다음 명령을 실행해야만 DB 종료 가능
겉으로 보면 마치
“PostgreSQL이 pg_ctl 없이 백그라운드로 혼자 올라온 것처럼”
보이는 상황이다.
2. 결론부터 말하면
이 현상은 PostgreSQL이 잘못 기동된 것도 아니고,
pg_ctl을 거치지 않은 기동도 아니다.
실제로는 pg_ctl runservice가 DB를 정상적으로 기동했지만,
Windows 서비스 초기화 타임아웃으로 인해
pg_ctl만 종료되고 postgres 프로세스만 잔존한 상태다.
3. onTune_DB 서비스 구조
onTune V4의 DB 서비스는 다음과 같이 등록되어 있다.
즉, 구조는 아래와 같다.
여기서 중요한 점은,
- postgres.exe는 DB 엔진 본체
- pg_ctl.exe는 Windows 서비스와 PostgreSQL을 연결하는 wrapper
- Windows는 pg_ctl을 ‘서비스 프로세스’로 인식한다는 점이다.
4. Windows 서비스가 요구하는 조건
Windows에서 서비스로 등록된 프로세스는
SCM(Service Control Manager)과 상태 통신을 유지해야 한다.
서비스 시작 시 요구되는 흐름은 다음과 같다.
- 서비스 시작
- START_PENDING 상태 보고
- 초기화가 길어질 경우 상태를 주기적으로 갱신
- 준비 완료 시 RUNNING 보고
이 과정을 정해진 시간 안에 못 하면
SCM은 해당 서비스를 ‘시작 실패’로 판단한다.

5. 핵심 원인: ServicesPipeTimeout (30초)
Windows에는 서비스 시작 타임아웃이 존재한다.
- 기본값: 30초
- 레지스트리 위치:
값이 없으면 기본 30,000ms(30초)가 적용된다.
- 타임아웃 (초) 커스텀 설정 방법




6. 고객사 환경에서 발생한 실제 시나리오
고객사 환경의 특징은 다음과 같았다.
- OS 부팅이 느림
- (추측) 디스크 I/O 지연
- (추측) 보안/백신
이 상황에서 실제로 벌어진 흐름은 다음과 같을 것 ...
- OS 부팅
- RPC / DCOM 관련 핵심 서비스 시작
- SCM이 onTune_DB 서비스 시작
- pg_ctl runservice 실행
- pg_ctl이 postgres.exe 기동
- PostgreSQL에서 WAL recovery, fsync, 데이터 디렉터리 초기화 수행
- 이 과정이 30초 초과
- pg_ctl은 postgres 초기화 대기로 블록됨
- SCM은 서비스 상태 갱신을 받지 못하고 시작 실패로 판단
- SCM이 pg_ctl 프로세스 종료
- 이미 떠 있던 postgres.exe는 그대로 잔존
결과적으로 다음 상태가 된다.
- pg_ctl.exe 없음
- postgres.exe 존재
- 서비스 Stop 불가
- pg_ctl stop 명령으로만 종료 가능 (pg_ctl.exe Stop -D "DATA 경로")
7. 왜 ‘백그라운드로 뜬 것처럼’ 보였나?
이 상태를 정확히 표현하면 다음과 같다.
PostgreSQL은 정상적으로 pg_ctl에 의해 기동되었으나,
Windows 서비스 초기화 타임아웃으로 인해
서비스 제어 주체(pg_ctl)가 사라지고
DB 프로세스만 고아 상태로 남은 것이다.
즉, PostgreSQL이 혼자 뜬 것도 아니고
pg_ctl 없이 뜬 것도 아니다.
8. 의존성(RPC / DCOM)과의 관계
onTune_DB 서비스의 의존성은 다음과 같다.
- Remote Procedure Call (RPC)
- DCOM Server Process Launcher
- RPC Endpoint Mapper
이 서비스들은 ‘시작됨(Started)’ 상태는 빨리 되지만,
내부 초기화가 끝나기까지는 시간이 걸릴 수 있다.
OS 부팅이 느린 환경에서는
의존 서비스는 Started 상태지만
IPC/DCOM 내부 안정화는 미완료 상태에서
DB 서비스가 기동되며 지연이 누적된다.
9. 정리
이 이슈의 본질은 다음 한 문장으로 정리된다.
Windows 환경에서 pg_ctl runservice는
PostgreSQL을 서비스로 실행하기 위한 타협적 구조이며,
느린 OS 부팅 환경에서는 서비스 시작 타임아웃으로 인해
pg_ctl이 종료되고 postgres 프로세스만 잔존하는 현상이 발생할 수 있다.
10. 대응 방법
단기 대응으로는
- ServicesPipeTimeout 값을 120초 이상으로 증가
- onTune_DB는 Automatic (Delayed Start) 유지
근본적인 해결로는
- pg_ctl runservice 방식 제거
Start / Stop을 명확히 제어하는 wrapper 서비스 도입 ? (스크립트를 통해서?)
11. 마무리
이 현상은 설정 실수도, PostgreSQL 버그도 아님...
느린 Windows 부팅 환경과 pg_ctl runservice 구조,
그리고 Windows 서비스 타임아웃이 겹치며 발생한 구조적 문제인듯하다.
Windows 환경에서 PostgreSQL을 서비스로 운영한다면
한 번쯤은 반드시 마주치게 될 케이스다.
'DB_postgreSQL' 카테고리의 다른 글
| [PostgreSQL] PostgreSQL에서 MVCC와 VACUUM의 역할과 작동 방식 (0) | 2025.05.13 |
|---|---|
| [PostgreSQL] DBexpress 파일(.dll) 의 사용 용도 (0) | 2025.04.28 |
| [PostgreSQL] 특정 테이블, 특정 컬럼 조회 (0) | 2025.02.03 |
| [PostgreSQL] 데이터베이스 관리 - 권한 (0) | 2024.12.12 |
| [PostgreSQL] 데이터베이스 관리 - 테이블스페이스 (0) | 2024.12.12 |