Что такое нотификации в PostgreSQL

Что проверяют

Понимаете ли вы, что LISTEN и NOTIFY это сигнал, а не очередь сообщений. Вопрос почти всегда ведёт к следующему: как вы собираетесь держать соединение в сервисе на Go и что произойдёт с уведомлением, пока слушателя нет.

Как отвечать

Механизм простой: клиент подписывается на именованный канал командой LISTEN, кто угодно шлёт в канал NOTIFY с короткой полезной нагрузкой, подписчики получают событие.

Дальше важные свойства, ради которых вопрос и задают.

Уведомление транзакционно: оно уходит только при фиксации, а одинаковые уведомления внутри транзакции схлопываются. Значит внутри триггера слать можно смело.

Доставка не гарантирована. Пока подписчик отключён, события для него просто не существуют, а очередь уведомлений в кластере ограничена, и при переполнении транзакции с NOTIFY начнут падать. Размер нагрузки тоже ограничен, поэтому в неё кладут идентификатор, а не данные.

Подписка живёт на конкретном соединении. Из пула она не работает: нужен выделенный коннект, который сервис держит сам и переподключает при обрыве. Внешний пулер в режиме транзакций ломает её вовсе.

conn, err := pool.Acquire(ctx) // отдельное соединение, не из общего пула
_, err = conn.Exec(ctx, "listen jobs_new")
for {
    n, err := conn.Conn().WaitForNotification(ctx)
    if err != nil { /* переподключение и повторный listen */ }
    worker.Wake(n.Payload)
}

Правильная схема: уведомление это только сигнал проснуться, состояние лежит в таблице, и воркер после пробуждения вычитывает её запросом с for update skip locked. Тогда потеря события стоит задержки до следующего опроса по таймеру, а не потерянной задачи.

Где спотыкаются

Строят на этом очередь задач и кладут данные в полезную нагрузку. Первый же разрыв соединения или перезапуск сервиса теряет сообщения, а на тестовом стенде это почти не ловится.

Подписываются через пул соединений. Работает ровно до момента, когда пул вернёт другое соединение, и выглядит как «уведомления иногда не приходят».

Не оставляют запасного пути. Слушатель обязан работать и без единого события: опрос таблицы по таймеру делает систему устойчивой, а NOTIFY превращает её из медленной в быструю.