LISTEN

LISTEN

현재 세션을 알림 채널(notification channel)의 수신자(listener)로 등록하는 명령이에요. NOTIFY 명령으로 같은 채널에 보낸 알림을 애플리케이션이 실시간으로 받아 처리하고 싶을 때 사용해요. 세션은 여러 채널에 동시에 수신자로 등록될 수 있어요.

출처: PostgreSQL 문서

본문

개요 (Synopsis)

LISTEN channel

설명 (Description)

LISTEN은 현재 세션을 이름이 channel인 알림 채널의 수신자로 등록해요. 현재 세션이 이미 이 알림 채널의 수신자로 등록되어 있다면 아무 일도 하지 않아요.

이 세션이든 같은 데이터베이스에 연결된 다른 세션이든 NOTIFY channel 명령이 호출될 때마다, 현재 그 알림 채널을 듣고 있는 모든 세션이 통지를 받고, 각 세션은 차례로 연결된 클라이언트 애플리케이션에 알려요.

세션은 UNLISTEN 명령으로 특정 알림 채널에 대한 등록을 해제할 수 있어요. 세션의 수신 등록은 세션이 끝나면 자동으로 지워져요.

클라이언트 애플리케이션이 알림 이벤트를 감지해야 하는 방법은 그것이 사용하는 PostgreSQL 애플리케이션 프로그래밍 인터페이스에 따라 달라요. libpq 라이브러리를 사용하면 애플리케이션이 LISTEN을 일반 SQL 명령으로 발행하고, 그 다음 알림 이벤트를 받았는지 알아보기 위해 주기적으로 PQnotifies 함수를 호출해야 해요. libpgtcl 같은 다른 인터페이스는 알림 이벤트를 처리하는 더 높은 수준의 메서드를 제공해요. 실제로 libpgtcl에서는 애플리케이션 프로그래머가 LISTEN이나 UNLISTEN을 직접 발행하지 않아야 해요. 사용 중인 인터페이스의 문서를 자세히 참고하세요.

파라미터 (Parameters)

*channel* — 알림 채널의 이름이에요(모든 식별자).

참고 (Notes)

LISTEN은 트랜잭션 커밋 시에 효과가 있어요. 이후 롤백되는 트랜잭션 안에서 LISTEN 또는 UNLISTEN이 실행되면, 듣고 있는 알림 채널 집합은 변하지 않아요.

LISTEN을 실행한 트랜잭션은 2단계 커밋을 위해 준비(prepare)될 수 없어요.

수신 세션을 처음 설정할 때 경쟁 조건(race condition)이 있어요. 동시에 커밋되는 트랜잭션이 알림 이벤트를 보내고 있다면, 새로 시작된 수신 세션은 그중 정확히 어느 것을 받게 될까요? 답은, 세션은 트랜잭션의 커밋 단계 중 어떤 순간 이후에 커밋된 모든 이벤트를 받는다는 거예요. 하지만 그것은 트랜잭션이 쿼리에서 관찰할 수 있었던 데이터베이스 상태보다 약간 늦은 시점이에요. 이로 인해 LISTEN 사용에 대한 다음 규칙이 생겨요. 먼저 그 명령을 실행(그리고 커밋!)하고, 그런 다음 새 트랜잭션에서 애플리케이션 로직이 필요로 하는 대로 데이터베이스 상태를 검사하고, 그 다음 알림에 의존해 데이터베이스 상태의 이후 변경을 알아내세요. 처음 받는 몇 개의 알림은 초기 데이터베이스 검사에서 이미 관찰한 갱신을 가리킬 수 있는데, 이것은 보통 해롭지 않아요.

NOTIFY에는 LISTEN과 NOTIFY의 사용에 대한 더 광범위한 논의가 담겨 있어요.

예제 (Examples)

psql에서 listen/notify 시퀀스를 구성하고 실행하려면:

LISTEN virtual;
NOTIFY virtual;
Asynchronous notification "virtual" received from server process with PID 8448.

호환성 (Compatibility)

SQL 표준에는 LISTEN 명령문이 없어요.

더 알아보기 (Learn more)

알림을 보내는 방법은 NOTIFY 문서를, 수신 등록을 해제하는 방법은 UNLISTEN 문서를 함께 보면 좋아요.