Люди, внимательно следящие за новинками в мире PostgreSQL, не по наслышке знакомы с блогом Хуберта 'depesz' Любашевского. А циклы его постов «Waiting for X.X» — настоящий кладезь полезной информации.

Не забыл он и про предстоящий релиз. На его блоге уже присутствуют 34 поста из цикла «Waiting for 9.0». Казалось бы, что угнаться за братом-поляком не представляется возможным. Но в очередной раз просматривая заметки к релизу, я обнаружил ценное нововведение, обделенное вниманием. А именно новую реализацию LISTEN/NOTIFY механизма.

Начну с сухих фактов. А в заключение опишу бурление жизни, сопровождавшее внедрение этого функционала.

Замена внутренней реализации NOTIFY/LISTEN

На данный момент (в версиях 8.х и ниже) механизм использует системную таблицу pg_listener для хранения уведомлений. В ней размещены все «слушатели», ожидающие какого-либо уведомления. В случае необходимости оповещения таблица сканируется и обновляется.

В новой версии всё это будет реализовано в виде очереди, расположенной в оперативной памяти. Во-первых, это даст огромный прирост в скорости. А во-вторых, данная реализация совместима с механизмом Hot Standby. Стоит отметить однако, что на данный момент не предусмотрено никакой возможности для HS-slave'a получать уведомления от master'a, но реализация запланирована на будущее.

Полезная нагрузка

Наконец-то, разработчики добавили второй параметр для команды NOTIFY, так называемый «payload» (полезная нагрузка). Планы по внедрению которого были еще до сотворения земной тверди.

Эта дополнительная информация представляет из себя обычную строку длиной до 8000 знаков. Для повседневных нужд, я полагаю, хватит с головой. В случае же больших данных рекомендуется сохранять их в таблице, а в уведомлении передавать идентификатор записи.

Коротко о главном

• Если NOTIFY выполняется в пределах транзакции, уведомления не отсылаются до тех пор, пока транзакция не будет завершена (COMMIT).
• Если «слушающая» сессия получает сигнал об уведомлении во время транзакции, само уведомление будет доставлено клиенту только по завершении транзакции вне зависимости от результата самой транзакции (COMMIT или ROLLBACK).
• Если уведомления дублируются (одинаковое имя канала и дополнительная информация), то сервер может объединить несколько уведомлений в одно.
• Уведомления от разных транзакций будут доставлены «как есть» без объединения, даже в случае дублирования.
• Уведомления будут доставлены в том порядке, в каком были посланы. В случае с транзакциями уведомления доставляются по порядку завершения транзакций.
• В случаях, когда невозможно представить имя канала или информацию строкой, удобно использовать функцию pg_notify(text, text). Например,
  SELECT pg_notify(current_user, 'pay' || 'load');
  
• Очередь уведомлений ограничена размером в 8Гб. При заполнении (что практически невозможно) транзакция, переполнившая очередь, будет откачена.
  

Как это было

Как я уже говорил, добавление нового параметра в формат команды NOTIFY было включено в TODO-список изначально. Видимо разработчики понимали, что в нынешнем виде этот функционал не претендует на лавры. Однако, объем работ, требующийся для реализации, пугал.

И вот 11 ноября 2009 года Йоахим Веланд (Joachim Wieland) представил на суд общественности патч с новой реализацией механизма уведомлений. В этой первой редакции размер дополнительной информации (payload) был ограничен 128 символами, что многих откровенно огорчило.

Автору приходили письма с неприкрытыми мольбами об увеличении длины дополнительного параметра. И цитадель пала. Размер в 8000 знаков, который мы имеем теперь продиктован лишь внутренними ограничениями.

Ветка обсуждения патча насчитала всего 63 письма. Глобальные вопросы были утрясены. Сообщество оживилось через несколько дней, когда Йоахим работал над деталями. Простой вопрос «Что следует делать при переполнении очереди» вызвал бурю эмоций. При том, что сама ситуация переполнения, вполне вероятно, не проявит себя никогда. Ведь для этого необходимо, чтобы на сервере скопилось ни много ни мало 2,147,483,647 уведомлений (теперь уже меньше из-за введенного ограничения в 8Гб).

Желающие насладиться логами священной войны милости прошу в архив.

Кому это нужно?

На этот вопрос каждый должен ответить для себя сам. Наличие дополнительного параметра открывает новые горизонты. Если до этого момента клиент получал лишь формальное известие об изменении, то теперь он имеет возможность узнать о сути произошедшего, не выполняя дополнительных запросов на сервере.

А тебе это нужно, %username?
_________
Текст подготовлен в ХабраРедакторе