Descripción

LISTEN registra la sesión actual como un oyente (listener) en el canal de notificación denominado canal. Si la sesión actual ya está registrada como oyente para este canal de notificación, no se hace nada.

Cada vez que se ejecuta el comando NOTIFY canal, ya sea por esta sesión o por otra conectada a la misma base de datos, todas las sesiones que estén escuchando actualmente en ese canal de notificación son notificadas, y cada una notificará a su vez a su aplicación cliente conectada.

Una sesión puede dejar de escuchar en un canal de notificación determinado con el comando UNLISTEN. Los registros de escucha de una sesión se borran automáticamente cuando finaliza la sesión.

El método que debe utilizar una aplicación cliente para detectar eventos de notificación depende de qué interfaz de programación de aplicaciones (API) de PostgreSQL utilice. Con la biblioteca libpq, la aplicación ejecuta LISTEN como un comando SQL ordinario, y luego debe llamar periódicamente a la función PQnotifies para averiguar si se han recibido eventos de notificación. Otras interfaces como libpgtcl proporcionan métodos de nivel superior para manejar eventos de notificación; de hecho, con libpgtcl el programador de la aplicación ni siquiera debería ejecutar LISTEN o UNLISTEN directamente. Consulta la documentación de la interfaz que estás utilizando para obtener más detalles.

Parámetros

Notas

LISTEN surte efecto al confirmarse la transacción (commit). Si se ejecuta LISTEN o UNLISTEN dentro de una transacción que posteriormente se deshace (rollback), el conjunto de canales de notificación que se están escuchando no cambia.

Una transacción que ha ejecutado LISTEN no se puede preparar para una confirmación en dos fases (two-phase commit).

Existe una condición de carrera al configurar por primera vez una sesión de escucha: si se están enviando eventos de notificación mediante transacciones que se confirman de forma concurrente, ¿cuáles de ellos recibirá exactamente la sesión recién oyente? La respuesta es que la sesión recibirá todos los eventos confirmados después de un instante durante el paso de confirmación de la transacción. Pero eso es ligeramente posterior a cualquier estado de la base de datos que la transacción podría haber observado en las consultas. Esto lleva a la siguiente regla para usar LISTEN: primero ejecuta (¡y confirma!) ese comando, luego, en una nueva transacción, inspecciona el estado de la base de datos según lo requiera la lógica de la aplicación, y luego confía en las notificaciones para enterarte de los cambios posteriores en el estado de la base de datos. Las primeras notificaciones recibidas podrían referirse a actualizaciones ya observadas en la inspección inicial de la base de datos, pero esto suele ser inofensivo.

La NOTIFY contiene una discusión más amplia sobre el uso de LISTEN y NOTIFY.

Ejemplos

Configurar y ejecutar una secuencia listen/notify desde psql:

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

Compatibilidad

No hay ninguna sentencia LISTEN en el estándar SQL.

Véase también