Re: Listen/Notify feedback

Поиск
Список
Период
Сортировка
От Brian Dunavant
Тема Re: Listen/Notify feedback
Дата
Msg-id CAJ2+uGWtZhmikCjEXDroorcq-A7P+uMm4Vum10-vOEDe1rUeFQ@mail.gmail.com
обсуждение исходный текст
Ответ на Listen/Notify feedback  (Rita <rmorgan466@gmail.com>)
Ответы Re: Listen/Notify feedback  (Rita <rmorgan466@gmail.com>)
Re: Listen/Notify feedback  (Michel Pelletier <pelletier.michel@gmail.com>)
Список pgsql-general
One aspect is if there is no one listening when a notify happens, the message is lost (e.g. no durability).   If this is important to you, it can be addressed by writing the messages to a table as well when you NOTIFY, and the listener deletes messages after they are processed.  On connection the listener can query the table to catch up on any missed messages, or messages that were mid-process during a crash.  This is trickier with more than one listener.   This isn't a whole lot more efficient than just using the table alone, but it saves you from having to poll so better response times.

On Sat, Jul 11, 2020 at 8:58 AM Rita <rmorgan466@gmail.com> wrote:
I am investigating various pub/sub tools such as ActiveMQ, Rabbit, Redis, etc.I came across Postgresql Listen/Notify and was easily able to write code to listen to messages. For the people who have been using this for a while: what are its downsides, things to consider when writing good code that use pub/sub, how do you deal with large messages, can I have subscribers listen to replica nodes?

Thanks
--
--- Get your facts first, then you can distort them as you please.--

В списке pgsql-general по дате отправления:

Предыдущее
От: luis.roberto@siscobra.com.br
Дата:
Сообщение: Join optimization
Следующее
От: Fabrízio de Royes Mello
Дата:
Сообщение: Re: Join optimization